Method for generating a secured boot image including an update boot loader for a secured update of the version information

In a secure boot method, an initial boot loader verifies a first digital signature included in a first boot loader using a public key. The first boot loader is executed if the first digital signature is valid. The first boot loader verifies a first message authentication code included in a second boot loader using a unique key. The second boot loader is executed if the first message authentication code is valid.

CROSS-REFERENCE TO RELATED APPLICATIONS

This U.S. non-provisional application claims the benefit of priority under 35 U.S.C. §119 to Korean Patent Application No. 2011-0012119 filed on Feb. 11, 2011 in the Korean Intellectual Property Office (KIPO), the entire content of which is herein incorporated by reference in its entirety.

BACKGROUND

1. Technical Field

The present disclosure relates to boot methods, and more particularly, to secure boot methods and methods of generating secure boot images.

2. Description of Related Art

A computing system performs a boot operation, which initializes devices and loads an operating system (OS) or a kernel by executing a boot image. If the computing system is booted using an unauthenticated boot image, illegal or malicious software may be executed in the computing system, and the computing system may be readily cloned.

In view of the foregoing, the integrity of a boot image is a component in system security.

SUMMARY

According to exemplary embodiments, in a secure boot method, an initial boot loader verifies a first digital signature included in a first boot loader using a public key. The first boot loader is executed if the first digital signature is valid. The first boot loader verifies a first message authentication code included in a second boot loader using a unique key. The second boot loader is executed if the first message authentication code is valid.

In some embodiments, to verify the first digital signature, the public key may be read from a public key storing unit, and integrity of an execution image included in the first boot loader may be checked by verifying the first digital signature using the read public key.

In some embodiments, to verify the first message authentication code, the unique key may be read from a unique key storing unit, a message authentication code may be generated using the read unique key and an execution image included in the second boot loader, and the generated message authentication code may be compared to the first message authentication code.

In some embodiments, the unique key may be read from the unique key storing unit via a unique key firewall, and the unique key firewall may be configured to block an access to the unique key storing unit after a boot operation is completed.

In some embodiments, the unique key storing unit may be set as a secure peripheral device, and may be inaccessible after a boot operation is completed.

In some embodiments, a physical address of the unique key storing unit may not be included in mapping information managed by a memory management unit.

In some embodiments, the public key may be read from a public key storing unit, and a second digital signature included in the second boot loader may be verified using the read public key. The second boot loader may be executed if the first message authentication code and the second digital signature are valid.

In some embodiments, a second digital signature included in the second boot loader may be verified using a public key included in the first boot loader. The second boot loader may be executed if the first message authentication code and the second digital signature are valid.

In some embodiments, the second boot loader may compare first purpose information included in the first boot loader to second purpose information included in the second boot loader, and a system may be terminated if the first purpose information does not match the second purpose information.

In some embodiments, a first build number included in the second boot loader stored in a nonvolatile memory device may be compared to a second build number included in an update boot loader stored in a volatile memory device, the second boot loader may be overwritten with the update boot loader in the nonvolatile memory device if the second build number is higher than the first build number, a message authentication code may be generated using the unique key and an execution image included in the update boot loader, and the generated message authentication code may be written as the first message authentication code to the update boot loader stored in the nonvolatile memory device.

In some embodiments, the second boot loader may verify a second message authentication code included in a kernel using the unique key, and the kernel may be executed if the second message authentication code is valid.

According to exemplary embodiments, in a method of generating a secure boot image of a system performing a secure boot operation, a boot image and a preliminary boot image are written to a nonvolatile memory device included in the system. An initial boot loader verifies a digital signature included in the boot image using a public key. The boot image is executed if the digital signature is valid. The boot image requests an authentication. An execution boot image is generated based on the preliminary boot image and a message authentication code generated using a unique key.

In some embodiments, the unique key is unique to the boot image among a plurality of copies of the boot image.

In some embodiments, to request the authentication, a first password may be received, and the first password may be compared to a second password included in the boot image.

In some embodiments, to request the authentication, an encrypted message may be generated by encrypting an original message using a public authentication key included in the boot image, a response message may be generated by decrypting the encrypted message using a private authentication key corresponding to the public authentication key, and the response message may be compared to the original message.

In some embodiments, the preliminary boot image may include a first preliminary boot loader, a second preliminary boot loader and a preliminary kernel. To generate the execution boot image, the boot image may be removed from the nonvolatile memory device, the first preliminary boot loader, the second preliminary boot loader and the preliminary kernel may be moved to locations corresponding to a first boot loader, a second boot loader and a kernel in the nonvolatile memory device, respectively, and a first message authentication code and a second message authentication code may be written to the moved second preliminary boot loader and the moved preliminary kernel, respectively.

According to exemplary embodiments, a secure boot system includes an integrated circuit having a processor for executing a boot image having a message authentication code and a digital signature, and a unique key storing unit storing a unique key for authenticating the message authentication code.

In some embodiments, the unique key storing unit further includes a memory device storing the unique key, a unique key firewall, and a control circuit controlling the unique key firewall not to output the unique key after a boot operation is completed by the secure boot system.

In some embodiments the memory device is one-time programmable.

In some embodiments, the processor further comprises a secure kernel in communication with the unique key storing unit.

In some embodiments, the secure boot system further includes a memory management unit disposed between the processor and the unique key storing unit, wherein the memory management unit does not store a physical address of the unique key storing unit.

As described above, in a secure boot method according to exemplary embodiments, a system may authenticate a boot image using a unique key that is unique for each system, and thus may perform a secure boot operation using the authenticated boot image. Further, a method of generating a secure boot image according to exemplary embodiments may mass-produce a plurality of systems having unique keys that are unique for each system.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

FIG. 1is a block diagram illustrating a system for performing a secure boot operation according to an exemplary embodiment of the present disclosure.

Referring toFIG. 1, a system100aincludes an integrated circuit110, an external volatile memory device130and an external nonvolatile memory device140a.

The integrated circuit110includes a processor core111, a unique key storing unit112, a public key storing unit113, a volatile memory (VM) controller114, a nonvolatile memory (NVM) controller115, an internal volatile memory device116(e.g., a random access memory (RAM)) and an internal nonvolatile memory device120(e.g., a read-only memory (ROM)). The processor core111may fetch an instruction or data, and may process the fetched instruction or data. According to exemplary embodiments, the integrated circuit110may be an application processor (AP), a microprocessor, a central processing unit (CPU), or the like.

The unique key storing unit112may store a unique key that is unique to the system. That is, different systems have different unique keys. The unique key may be referred to as a Device Unique Secret Key (DUSK). In some embodiments, the unique key may be used during a boot operation. In other embodiments, a key may be derived from the unique key using a key derivation function (KDF), and the derived key may be used during the boot operation. For example, the unique key storing unit112may be implemented by a one-time programmable (OTP) memory, a mask ROM, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable memory (EEPROM), a flash memory, or the like.

The public key storing unit113may store a public key for verifying digital signatures148a,158aand168a. Alternatively, the public key storing unit113may store information related to the public key, and the public key may be provided from an external device by using the related information during the boot operation. For example, the public key storing unit113may be implemented by an OTP memory, a ROM, a PROM, an EPROM, an EEPROM) a flash memory, or the like.

The volatile memory controller114may control an operation of the external volatile memory device130, and the nonvolatile memory controller115may control an operation of the external nonvolatile memory device140a. For example, the volatile memory controller114may control the external volatile memory device130to perform a read operation or a write operation, and the nonvolatile memory controller115may control the external nonvolatile memory device140ato perform a read operation or a write operation.

The internal volatile memory device116may serve as a cache memory or a working memory for the processor core111. For example, the internal volatile memory device116may be implemented by a RAM, such as a static random access memory (SRAM), an embedded dynamic random access memory (EDRAM), etc.

The internal nonvolatile memory device120may store an initial boot loader121. For example, the internal nonvolatile memory device120may be implemented by an OTP memory, a ROM, a PROM, an EPROM, an EEPROM, a flash memory, or the like. Once the system100ais powered on, the initial boot loader (IBL)121may be executed. The initial boot loader121may include signature verification code that verifies a first digital signature148aincluded in a first boot loader141a. The signature verification code may be referred to as a “signature verifier.” The initial boot loader121may initialize the nonvolatile memory controller115and/or the volatile memory controller114, and may load the first boot loader141afrom the external nonvolatile memory device140ainto the internal volatile memory device116or the external volatile memory device130. According to exemplary embodiments, the unique key storing unit112, the public key storing unit113and the internal nonvolatile memory device120may be implemented as separate nonvolatile memory devices, or at least two of the unique key storing unit112, the public key storing unit113and the internal nonvolatile memory device120may be implemented as one nonvolatile memory device.

The external volatile memory device130may serve as a main memory. For example, the external volatile memory device130may be implemented by a dynamic random access memory (DRAM), a static random access memory (SRAM), a mobile DRAM, or the like.

The external nonvolatile memory device140amay store a boot image including a first boot loader141a, a second boot loader151aand a kernel161a. For example, the external nonvolatile memory device140amay be implemented by an EEPROM, a flash memory, a phase change random access memory (PRAM), a resistance random access memory (RRAM), a nano floating gate memory (NFGM), a polymer random access memory (PoRAM), a magnetic random access memory (MRAM), a ferroelectric random access memory (FRAM), or the like.

The first boot loader141amay include a first execution image142aand a first digital signature148a. The first execution image142amay include an initialization code for initializing at least one device included in the system100a, a code for loading the second boot loader151ainto the internal volatile memory device116or the external volatile memory device130, a signature verification code143afor verifying a second digital signature158aincluded in the second boot loader151a, and a message authentication code (MAC) verification code144afor verifying a first message authentication code159aincluded in the second boot loader151a. The MAC verification code144amay be referred to as a “MAC verifier.” The first digital signature148amay be generated by signing the first execution image142ausing a private key corresponding to the public key. When the initial boot loader121verifies the first digital signature148a, the initial boot loader121may determine the first digital signature148ato be invalid if the first execution image142ahas been changed. Thus, the initial boot loader121may check the integrity of the first execution image142aincluded in the first boot loader141aby verifying the first digital signature148a.

The second boot loader151amay include a second execution image152a, the second digital signature158a, and the first message authentication code159a. The second execution image152amay include an initialization code for initializing at least one device included in the system100a, a code for loading the kernel161ainto the external volatile memory device130, a signature verification code153afor verifying a third digital signature168aincluded in the kernel161a, and a MAC verification code154afor verifying a second message authentication code169a. The second digital signature158amay be generated by signing the second execution image152ausing the private key corresponding to the public key. The first boot loader141amay check integrity of the second execution image152aincluded in the second boot loader151aby verifying the second digital signature158a.

The first message authentication code159amay be generated using the second execution image152aalong with the unique key stored in the unique key storing unit112or the key derived from the unique key. For example, the first message authentication code159amay be generated by a MAC algorithm that receives the unique key or the derived key as a secret key input and receives the second execution image152aas a message input. The MAC algorithm may employ a cryptographic hash function, a block cipher algorithm, universal hashing, or the like. For example, the MAC algorithm may be a message authentication code based on a universal hashing (UMAC) algorithm, a hash-based message authentication code (HMAC) algorithm, a cipher-based message authentication code (CMAC) algorithm, a block cipher-based message authentication code algorithm using universal hashing (VMAC) algorithm, or the like. Confidentiality and integrity of the second boot loader151amay be maintained by verifying the first message authentication code159aincluded in the second boot loader151a.

The kernel161amay include a third execution image162a, the third digital signature168a, and the second message authentication code169a. The third execution image162amay be loaded into the external volatile memory device130to operate the system100a. The third digital signature168amay be generated by signing the third execution image162ausing the private key corresponding to the public key. The second boot loader151amay check the integrity of the third execution image162aincluded in the kernel161aby verifying the third digital signature168a. The second message authentication code169amay be generated using the third execution image162aalong with the unique key or the derived key. Confidentiality and integrity of the kernel161amay be maintained by verifying the second message authentication code169aincluded in the kernel161a.

As described above, the system100aaccording to an exemplary embodiment of the present disclosure may perform a secure boot operation with an authenticated boot image by verifying the message authentication code included in the boot image using the unique key that is unique to the system. For example, if an unauthenticated boot image or a boot image of another system is cloned to the external nonvolatile memory device140a, the system100amay be prevented from booting using the cloned boot image by verifying the message authentication code included in the cloned boot image.

AlthoughFIG. 1illustrates an example where two boot loaders151aand161aare stored in the external nonvolatile memory device140a. In some embodiments, the external nonvolatile memory device140amay store one or more boot loaders. For example, the initial boot loader121may load one boot loader, and the boot loader may directly load the kernel161a. In other examples, the initial boot loader121and three boot loaders stored in the external nonvolatile memory device140aare sequentially loaded, and then the kernel161amay be loaded.

FIGS. 2A and 2Bare flow charts illustrating a secure boot method according to an exemplary embodiment of the present disclosure.

Referring toFIGS. 1,2A and2B, a processor core111may execute an initial boot loader121stored in an internal nonvolatile memory device120(S210). The initial boot loader121may load a first boot loader141afrom an external nonvolatile memory device140ainto an internal volatile memory device116or an external volatile memory device130, and may verify a first digital signature148aincluded in the first boot loader141ausing a public key stored in a public key storing unit113(S211). For example, the initial boot loader121may read the public key from the public key storing unit113, and may check integrity of a first execution image142aby executing a signature verification algorithm on the read public key, the first execution image142aand the first digital signature148a. If the first digital signature148ais invalid (S212: NO), a secure boot operation may be stopped, and a boot operation of the system100amay be terminated (S250).

If the first digital signature148ais valid (S212: YES), the processor core111may execute the first boot loader141a(S220). The first boot loader141amay load a second boot loader151ainto the internal volatile memory device116or the external volatile memory device130, and may verify a first message verification code159aincluded in the second boot loader151ausing a unique key stored in a unique key storing unit112(S221). For example, a MAC verification code144aincluded in the first execution image142amay read the unique key from the unique key storing unit112, and may generate a message authentication code by executing a MAC algorithm on the read unique key and a second execution image152aincluded in the second boot loader151a. The MAC verification code144amay check confidentiality and integrity of the second boot loader151aby comparing the generated message authentication code to the first message verification code159a. If the generated message authentication code does not match the first message verification code159a, the first message verification code159amay be determined as invalid (S222: NO), and a boot operation of the system100amay be terminated (S250).

If the generated message authentication code matches the first message verification code159a, the first message verification code159amay be determined as valid (S222: YES), and the first boot load141amay verify a second digital signature158aincluded in the second boot loader151ausing the public key (S223). For example, a signature verification code143aincluded in the first execution image142amay check integrity of the second execution image152aby executing a signature verification algorithm on the public key, the second execution image152aand the second digital signature158a. If the second execution image152aor the second digital signature158ais changed, the second digital signature158amay be determined as invalid (S224: NO), and a boot operation of the system100amay be terminated (S250).

If the second digital signature158ais valid (S224: YES), the processor core111may execute the second boot loader151a(S230). The second boot loader151amay load a kernel161ainto the external volatile memory device130, and may verify a second message verification code169aincluded in the kernel161ausing the unique key (S231). For example, a MAC verification code154aincluded in the second execution image152amay generate a message authentication code by executing a MAC algorithm on the unique key and a third execution image162aincluded in the kernel161a. The MAC verification code154amay check confidentiality and integrity of the kernel161by comparing the generated message authentication code to the second message verification code169a. If the generated message authentication code does not match the second message verification code169a, the second message verification code169amay be determined as invalid (S232: NO), and a boot operation of the system100amay be terminated (S250).

If the generated message authentication code matches the second message verification code169a, the second message verification code169amay be determined as valid (S232: YES), and the second boot load151amay verify a third digital signature168aincluded in the kernel161ausing the public key (S233). For example, a signature verification code153aincluded in the second execution image152amay check integrity of the third execution image162aby executing a signature verification algorithm on the public key, the third execution image162aand the third digital signature168a. If the third execution image162aor the third digital signature168ais changed, the third digital signature168amay be determined as invalid (S234: NO), and a boot operation of the system100amay be terminated (S250).

If the third digital signature168ais valid (S234: YES), the processor core111may execute the kernel161ato operate the system100a(S240). Accordingly, the secure boot operation may be completed, and the system100amay operate.

As describe above, in a secure boot method according to an exemplary embodiment of the present disclosure, the first message authentication code159aincluded in the second boot loader151aand the second message authentication code169aincluded in the kernel161amay be verified using the unique key that is unique for each system. Accordingly, the secure boot method may prevent the system100afrom being booted by an unauthenticated boot image or a cloned boot image.

FIG. 3is a diagram for describing an example of a method of protecting a private key included in a system ofFIG. 1.

Referring toFIG. 3, a unique key storing unit112aincludes an OTP memory171, a unique key firewall172and a control circuit173.

The OTP memory171may store a unique key that is unique to the system or integrated circuit. That is, different systems have different unique keys. The unique key may be written to the OTP memory171when an integrated circuit110illustrated inFIG. 1is manufactured. In some embodiments, the unique key storing unit112amay include a mask ROM, a PROM, an EPROM, an EEPROM, a flash memory, etc. instead of the OTP memory171.

The unique key firewall172may output the unique key stored in the OTP memory171during a secure boot operation, and may block an access to the OTP memory171after the secure boot operation. For example, a processor core111illustrated inFIG. 1may read the unique key from the OTP memory171via the unique key firewall172during the secure boot operation. After the secure boot operation is completed, the processor core111may transmit a signal indicating that the secure boot operation is completed to the control circuit173, and the control circuit173may control the unique key firewall172not to output the unique key.

As described above, since the unique key firewall172may make the OTP memory171inaccessible after the secure boot operation is completed, the unique key may be secured. Accordingly, access to the unique key and/or a boot image, such as by a hacking, may be blocked.

FIG. 4is a diagram for describing another example of a method of protecting a private key included in a system ofFIG. 1.

Referring toFIG. 4, a processor core111amay execute a normal kernel181in a normal domain, and may execute a secure kernel182in a secure domain. A unique key storing unit112may be set as a secure peripheral device in the secure domain. An initial boot loader121, a first boot loader141aand a second boot loader151aillustrated inFIG. 1may be set to be executed in the secure domain, and at least a portion of a kernel161aillustrated inFIG. 1may be set to be executed in the normal domain. Accordingly, the unique key storing unit112may be accessed during a secure boot operation, and may not be accessed after the secure boot operation. Further, the processor core111amay execute a monitor183for transferring data or a context between the normal domain and the secure domain. This security technique may be referred to as a “TRUSTZONE” technique, as to secure integrated circuits, microprocessors and microprocessor cores.

As described above, since the unique key storing unit112may be inaccessible after the secure boot operation is completed, the unique key may be secured.

FIG. 5is a diagram for describing still another example of a method of protecting a private key included in a system ofFIG. 1.

Referring toFIG. 5, a processor core111bmay access an external volatile memory device130and an external nonvolatile memory device140ausing a memory management unit (MMU)190included in a kernel after a secure boot operation is completed. The MMU190may convert a logical address LA provided from the processor core111binto physical addresses PA1and PA2of the external volatile memory device130and the external nonvolatile memory device140a, respectively. The MMU190may manage mapping information including the physical addresses PA1and PA2of the external volatile memory device130and the external nonvolatile memory device140a. However, the mapping information managed by the MMU190may not include a physical address of a unique key storing unit112, and thus the logical address LA provided from the processor core111bmay not be converted into the physical address of the unique key storing unit112.

As described above, since the logical address LA may not be converted into the physical address of the unique key storing unit112after the secure boot operation is completed, the unique key storing unit112may not be accessed after the secure boot operation, and a unique key stored in the unique key storing unit112may be secured.

FIG. 6is a block diagram for describing an example of a method of updating a boot image according to an exemplary embodiment of the present disclosure.

FIG. 6illustrates an example where a second boot loader151ais updated. Referring toFIG. 6, an update boot loader251amay be downloaded from a host (not shown) into an external volatile memory device130. For example, a system including an integrated circuit110may be coupled to the host through a universal serial bus (USB), and the update boot loader251amay be written to the external volatile memory device130through the USB. In other examples, the update boot loader251amay be wired or wirelessly downloaded from a remote host through an Ethernet, a mobile network (e.g., a 3G network), or the like.

The update boot loader251amay include an execution image252aand a digital signature258a, and meaningless data259a(e.g., data of which all values are “0”) may be stored in a location to which a message authentication code159ais to be written. The digital signature258aincluded in the update boot loader251amay be verified using a public key stored in a public key storing unit113. If the digital signature258ais valid, the update boot loader251astored in the external volatile memory device130may be written to an external nonvolatile memory device140a. For example, the second boot loader151amay be overwritten with the update boot loader251a. After the update boot loader251ais stored in the external nonvolatile memory device140a, the message authentication code159amay be generated using a unique key stored in a unique key storing unit112and the execution image252aincluded in the update boot loader251a. The generated message authentication code159amay be written to the update boot loader251astored in the external nonvolatile memory device140a, or the second boot loader151a. Accordingly, a boot image having a message authentication code that is to be verified using a unique key may be updated.

According to exemplary embodiments, a boot image update operation may be performed by one of boot loaders during a secure boot operation, or may be performed by a kernel after the secure boot operation.

FIG. 7is a flow chart illustrating a method of generating a secure boot image of a system performing a secure boot operation according to exemplary embodiments, andFIG. 8is a diagram for describing a method of generating a secure boot image illustrated inFIG. 7.

Referring toFIGS. 1,7and8, a gang writer400may write substantially the same boot image410and substantially the same preliminary boot image420ato a plurality of external nonvolatile memory devices140a,140a1and140a2for a plurality of systems (S300). The boot image410may include an execution image411and a digital signature412, and the preliminary boot image420amay include a first preliminary boot loader421a, a second preliminary boot loader431aand a preliminary kernel441a. The execution image411of the boot image410may include a code for removing the boot image410from the external nonvolatile memory device140a, and a code for moving the first preliminary boot loader421a, the second preliminary boot loader431aand the preliminary kernel441ato locations corresponding to a first boot loader141a, a second boot loader151aand a kernel161a. The first preliminary boot loader421a, the second preliminary boot loader431aand the preliminary kernel441amay include execution images422a,432aand442aand digital signatures428a,438aand448a, respectively.

When a system100ais initially booted after the boot image410and the preliminary boot image420aare written to the external nonvolatile memory device140a, an initial boot loader121stored in an internal nonvolatile memory device120may be executed (S310). The initial boot loader121may load the boot image410from the external nonvolatile memory device140ainto an internal volatile memory device116or an external volatile memory device130, and may verify the digital signature412included in the boot image410using a public key stored in a public key storing unit113(S311). If the digital signature412of the boot image410is invalid (S312: NO), and a boot operation of the system100amay be terminated (S340).

If the digital signature412of the boot image410is valid (S312: YES), the boot image410may be executed (S320). The executed boot image410may request an authentication (S321). In some embodiments, the boot image410may receive a first password from a user, and may compare the first password to a second password included in the boot image410. The boot image410may validate the authentication if the first password matches the second password. In other embodiments, the boot image410may request the authentication in a challenge-response manner. For example, the boot image410may generate an encrypted message by encrypting an original message using a public authentication key included in the boot image410, and may provide the encrypted message to an external host (not shown). The host may generate a response message by decrypting the encrypted message using a private authentication key corresponding to the public authentication key, and may provide the response message to the system100a. The boot image410may validate the authentication if the response message matches the original message. If the authentication is failed (S322: NO), and a boot operation of the system100amay be terminated (S340).

If the authentication is passed (S322: YES), the execution image411of the loaded and executed boot image410may remove the boot image410from the external nonvolatile memory device140a(S323), and may generate an execution boot image450aby moving the first preliminary boot loader421a, the second preliminary boot loader431aand the preliminary kernel441ato locations corresponding to the first boot loader141a, the second boot loader151aand the kernel161a, respectively (S324). For example, the first preliminary boot loader421amay be moved to a location corresponding to the first boot loader141a(e.g., a location of the removed boot image410), and thus the first preliminary boot loader421amay be loaded and executed as the first boot loader141aby the initial boot loader121during a next boot operation. The execution image411of the loaded and executed boot image410may write a first message authentication code159aand a second message authentication code169ato the moved second preliminary boot loader431a(i.e., the second boot loader151a) and the moved preliminary kernel441a(i.e., the kernel161a) (S325). For example, the execution image411of the boot image410may generate the first message authentication code159ausing a unique key stored in a unique key storing unit112and the execution image432aof the moved second preliminary boot loader431a, and may write the generated first message authentication code159ato the moved second preliminary boot loader431a. Further, the execution image411of the boot image410may generate the second message authentication code169ausing the unique key and the execution image442aof the moved preliminary kernel441a, and may write the generated second message authentication code169ato the moved preliminary kernel441a.

After the execution boot image450aincluding the first and second message authentication codes159aand169ais generated, the system100amay be rebooted (S330). A secure boot method according to an exemplary embodiment of the present disclosure may be performed while the system100ais rebooted.

As described above, although substantially the same boot image410and substantially the same preliminary boot image420aare written to the plurality of external nonvolatile memory devices140a,140a_1and140a_2for the plurality of systems, the execution boot image450amay be generated including unique message authentication code159aand169afor each system. Accordingly, the system performing a secure boot operation may be readily mass-produced.

FIG. 9is a diagram for describing an example of an authentication step in a method of generating a secure boot image illustrated inFIG. 7.

Referring toFIG. 9, a system500, such as a mobile phone, may receive a password from a user via an input device510, such as a key pad, a touch screen, voice control means, etc. For example, a manufacturer of the system500may input the password after the system500is manufactured. A mass-produced boot image of the system500may include a code for initializing the input device510, and the mass-produced boot image may be executed when the system500is initially booted after the system500is manufactured. A mass-produced boot image according to an embodiment of the present disclosure is a boot image created for more than one system. That is the boot image may be embodied in more then one system.

The system500may compare the received password to a password included in the mass-produced boot image, and may generate an execution boot image in case of a match of the passwords. Accordingly, even if the mass-produced boot image is exposed to a hacker, the execution boot image may be prevented from being generated by the hacker. Thus, an image rollback attack or a device cloning attack may be blocked.

FIG. 10is a diagram for describing another example of an authentication step in a method of generating a secure boot image illustrated inFIG. 7.

Referring toFIG. 10, a system610, such as a mobile phone, may request an authentication in a challenge-response manner. For example, a boot image of the system610may generate an encrypted message by encrypting an original message using a public authentication key included in the boot image, and may provide the encrypted message to an external host620. The external host620may generate a response message by decrypting the encrypted message using a private authentication key corresponding to the public authentication key, and may provide the response message to the system610. The boot image of the system610may compare the response message to the original message, and may validate the authentication in case of a match of the response message and the original message. In some embodiments, the encrypted message may include a data structure for checking validity of the encrypted message, and the external host620may generate the response message only if the encrypted message is valid.

For example, after the system610is manufactured, a manufacturer of the system610may connect the system610to the external host620, such as a computer storing the private authentication key, through a USB to perform the authentication. In other examples, the manufactured system610may be provided to a customer, and the system610may display the encrypted message. To perform the authentication, the customer may inform the manufacturer of the displayed message, and the manufacturer may inform the customer of the response message corresponding to the displayed message. In still other examples, when the system610is initially booted after the system610is provided to a customer, the system610may be connected to the external host650through an Ethernet, a mobile network (e.g., a 3G network), or the like, to perform the authentication.

FIG. 11is a flow chart illustrating a method of generating a secure boot image of a system performing a secure boot operation according to exemplary embodiments, andFIGS. 12A and 12Bare flow charts illustrating a method of generating a secure boot image of a system performing a secure boot operation according to exemplary embodiments.

Referring toFIGS. 11,12A and12B, a system100bincludes an integrated circuit110and an external nonvolatile memory device140b. The first and second boot loaders141band151billustrated inFIG. 11may include public keys145band155b.

In a secure boot method, an initial boot loader121stored in an internal nonvolatile memory device120may be executed (S710). The initial boot loader121may load the first boot loader141bstored in the external nonvolatile memory device140b, and may verify a first digital signature148bincluded in the first boot loader141busing a public key stored in a public key storing unit113(S711). If the first digital signature148bis invalid (S712: NO), and a boot operation of the system100bmay be terminated (S750).

If the first digital signature148bis valid (S712: YES), the first boot loader141bmay be executed (S720). A first execution image142bof the first boot loader141bmay load a second boot loader151b, and a MAC verification code144bof the first execution image142bmay verify a first message authentication code159bincluded in the second boot loader151busing a unique key stored in a unique key storing unit112(S721). If the first message authentication code159bis invalid (S722: NO), and a boot operation of the system100bmay be terminated (S750).

If the first message authentication code159bis valid (S722: YES), a signature verification code143bof the first execution image142bmay verify a second digital signature158bincluded in the second boot loader151bby selectively using a public key145bincluded in the first boot loader141bor the public key stored in the public key storing unit113depending on whether first boot loader141bincludes the public key145b. If the public key145bdoes not exist in the first boot loader141b(e.g., in a case where values of “0” are written to a public key region of the first boot loader141b) (S723: NO), the second digital signature158bmay be verified using the public key stored in the public key storing unit113(S724). If the public key145bexists in the first boot loader141b(S723: YES), the second digital signature158bmay be verified using the public key145bincluded in the first boot loader141b(S725). If the second digital signature158bis invalid (S726: NO), and a boot operation of the system100bmay be terminated (S750).

If the second digital signature158bis valid (S726: YES), the second boot loader151bmay be executed (S730). A second execution image152bof the second boot loader151bmay load a kernel161b, and a MAC verification code154bof the second execution image152bmay verify a second message authentication code169bincluded in the kernel161busing the unique key (S731). If the second message authentication code169bis invalid (S732: NO), and a boot operation of the system100bmay be terminated (S750).

If the second message authentication code169bis valid (S732: YES), and a public key155bdoes not exist in the second boot loader151b(S733: NO), a signature verification code153bof the second execution image152bmay verify a third digital signature168bof the kernel161busing a public key that is used to verify the second digital signature158b(S734). For example, in a case where the second digital signature158bis verified using the public key145bincluded in the first boot loader141b, the third digital signature168bmay be also verified using the public key145bincluded in the first boot loader141b. In a case where the second digital signature158bis verified using the public key stored in the public key storing unit113, the third digital signature168bmay be also verified using the public key stored in the public key storing unit113.

If the second message authentication code169bis valid (S732: YES), and the public key155bexists in the second boot loader151b(S733: YES), the signature verification code153bof the second execution image152bmay verify the third execution image162band the third digital signature168bof the kernel161busing the public key155bincluded in the second boot loader151b(S735). If the third execution image162bor the third digital signature168bis changed, the third digital signature168bmay be determined as invalid (S736: NO), and a boot operation of the system100bmay be terminated (S750).

If the third digital signature168bis valid (S736: YES), a third execution code161bof the kernel161bmay be executed (S740). Thus, a secure boot operation may be completed, and the system100bmay normally operate.

As described above, in a secure boot method according to exemplary embodiments, the message authentication code159band169may be verified using the unique key that is unique to the system, and thus the system100bmay be prevented from being booted by an unauthenticated boot image or a cloned boot image. Further, in the secure boot method according to exemplary embodiments, the public key145band155bincluded in the boot loader141band151bor the public key stored in the public key storing unit113may be selectively used depending on whether the public key145band155bexists in the boot loader141band151b, and thus the public key may be readily and securely updated.

FIG. 13is a block diagram for describing an example of a method of updating a boot image according to exemplary embodiments.

FIG. 13illustrates an example where first and second boot loaders141band151bare updated, and a public key145bfor verifying a digital signature158bof the second boot loader151bis updated. Referring toFIG. 13, a first update boot loader751band a second update boot loader761bmay be downloaded from a host (not shown) into an external volatile memory device130. For example, the first and second update boot loaders751band761bmay be downloaded through a USB, an Ethernet, a mobile network, etc.

The first update boot loader751amay include an execution image752b, an update public key755band a digital signature758b, and the second update boot loader761bmay include an execution image762b, and an update digital signature768b. In the second update boot loader761b, meaningless data769bmay be stored in a location to which a message authentication code159bis to be written. The digital signature758aincluded in the first update boot loader751bmay be verified using a public key stored in a public key storing unit113. If the digital signature758ais valid, the first boot loader141bmay be overwritten with the first update boot loader751b.

The update digital signature768bincluded in the second update boot loader761bmay be verified using the update public key755bof the first update boot loader751b. If the update digital signature768bis valid, the second boot loader151bmay be overwritten with the second update boot loader761b. After the second update boot loader761bis stored in an external nonvolatile memory device140b, the message authentication code159bmay be generated using a unique key stored in a unique key storing unit112and the execution image762bincluded in the second update boot loader761b. The generated message authentication code159bmay be written to the second update boot loader761bstored in the external nonvolatile memory device140b, or the second boot loader151b. Accordingly, a boot image having a message authentication code that is to be verified using a unique key may be updated. Further, the public key145band the digital signature158bmay be readily and securely updated.

FIG. 14is a block diagram illustrating a system performing a secure boot operation according to exemplary embodiments, andFIGS. 15A and 15Bare flow charts illustrating a method of generating a secure boot image of a system performing a secure boot operation according to exemplary embodiments.

Referring toFIGS. 14,15A and15B, a system100cincludes an integrated circuit110and an external nonvolatile memory device140c. A boot image illustrated inFIG. 14may include purpose information146c,156cand166cand purpose verification codes157cand167c.

In a secure boot method, an initial boot loader121stored in an internal nonvolatile memory device120may be executed (S810). The initial boot loader121may load the first boot loader141cstored in the external nonvolatile memory device140c, and may verify a first digital signature148cincluded in the first boot loader141cusing a public key stored in a public key storing unit113(S811). If the first digital signature148cis invalid (S812: NO), and a boot operation of the system100cmay be terminated (S850).

If the first digital signature148cis valid (S812: YES), the first boot loader141cmay be executed (S820). A first execution image142cof the first boot loader141cmay load a second boot loader151c, and a MAC verification code144cof the first execution image142cmay verify a first message authentication code159cincluded in the second boot loader151cusing a unique key stored in a unique key storing unit112(S821). If the first message authentication code159cis invalid (S822: NO), and a boot operation of the system100cmay be terminated (S750). If the first message authentication code159cis valid (S822: YES), a signature verification code143cof the first execution image142cmay verify a second digital signature158cincluded in the second boot loader151cusing the public key (S823). If the second digital signature158cis invalid (S824: NO), and a boot operation of the system100cmay be terminated (S850).

If the second digital signature158cis valid (S824: YES), the second boot loader151cmay be executed (S830). A purpose verification code157cof a second execution image152cmay compare first purpose information146cincluded in the first boot loader141cto second purpose information156cincluded in the second boot loader151c(S831). For example, each of the purpose information146c,156cand166cmay indicate that a corresponding boot loader141cand151cor kernel161chas one of a development purpose, a mass product purpose and an execution purpose. The purpose verification code157cmay be referred to as a “purpose verifier.” If the first purpose information146cdoes not match the second purpose information156c(S832: NO), and a boot operation of the system100cmay be terminated (S850).

If the first purpose information146cmatches the second purpose information156c(S832: YES), the second execution image152cof the second boot loader151cmay load a kernel161c, and a MAC verification code154cof the second execution image152cmay verify a second message authentication code169cincluded in the kernel161cusing the unique key (S833). If the second message authentication code169cis invalid (S834: NO), and a boot operation of the system100cmay be terminated (S750). If the second message authentication code169cis valid (S834: YES), a signature verification code153cof the second execution image152cmay verify a third digital signature168cof the kernel161cusing the public key (S835). If the third digital signature168cis invalid (S836: NO), and a boot operation of the system100cmay be terminated (S750).

If the third digital signature168bis valid (S836: YES), the kernel161cmay be executed (S840). A purpose verification code167cof a third execution image162cmay compare the second purpose information156cincluded in the second boot loader151cto third purpose information166cincluded in the kernel161c(S841). If the second purpose information156cdoes not match the third purpose information166c(S842: NO), and a boot operation of the system100cmay be terminated (S850). If the second purpose information156cmatches the third purpose information166c(S842: YES), a secure boot operation may be completed, and the system100amay normally operate.

As described above, in a secure boot method according to an exemplary embodiment of the present disclosure, the message authentication code159cand169cmay be verified using the unique key that is unique for each system, and thus the system100cmay be prevented from being booted by an unauthenticated boot image or a cloned boot image. Further, in the secure boot method according to an exemplary embodiment of the present disclosure, the secure boot operation may be normally completed in case of a match of the purpose information146c,156cand166c. Accordingly, even if a boot image for the development or the boot image is exposed to a hacker, the system100cmay be prevented from being booted by the exposed boot image.

FIG. 16is a block diagram illustrating a system performing a secure boot operation according to an exemplary embodiment of the present disclosure.

Referring toFIG. 16, a system100dincludes an integrated circuit110and an external nonvolatile memory device140d. A boot image illustrated inFIG. 16may include build numbers150d,160dand170d.

A first boot loader141dmay include a first execution image142dand a first digital signature148d, and the first execution image142dmay include a signature verification code143d, a MAC verification code144dand a first build number150drepresenting version information of the first boot loader141d. A second boot loader151dmay include a second execution image152d, a second digital signature158dand a first message authentication code159d, and the second execution image152dmay include a signature verification code153d, a MAC verification code154dand a second build number160drepresenting version information of the second boot loader151d. A kernel161dmay include a third execution image162d, a third digital signature168dand a second message authentication code169d, and the third execution image162dmay include a third build number170drepresenting version information of the kernel170d.

In the system100daccording to an exemplary embodiment of the present disclosure, the first boot loader141d, the second boot loader151dand the kernel161dmay be updated using the first build number150d, the second build number160dand the third build number170d, respectively. Accordingly, a boot image may be prevented from being updated from a newer version to an older version.

FIG. 17is a block diagram for describing an example of a method of updating a boot image according to an exemplary embodiment of the present disclosure.

FIG. 17illustrates an example where a second boot loader151dis updated. Referring toFIG. 17, an update boot loader251dmay be downloaded from a host (not shown) into an external volatile memory device130. For example, the update boot loader251dmay be downloaded through a USB, an Ethernet, a mobile network, etc.

The update boot loader251dmay include an execution image252d, a build number260drepresenting version information of the update boot loader251d, and a digital signature258d. In the update boot loader251d, meaningless data259dmay be stored in a location to which a message authentication code159dis to be written. The digital signature258dincluded in the update boot loader251dmay be verified using a public key stored in a public key storing unit113. If the digital signature258ais valid, the build number260dof the update boot loader251dmay be compared to a build number160dof the second boot loader151dstored in the external nonvolatile memory device140d. If the build number260dof the update boot loader251dis higher than the build number160dof the second boot loader151d, the second boot loader151dmay be overwritten with the update boot loader251d. After the update boot loader251dis stored in the external nonvolatile memory device140d, the message authentication code159dmay be generated using a unique key stored in a unique key storing unit112and the execution image252dincluded in the update boot loader251d, and may be written to the update boot loader251dstored in the external nonvolatile memory device140d, or the second boot loader151d. Accordingly, a boot image may be readily and securely updated using version information.

FIG. 18is a block diagram illustrating a mobile system according to an exemplary embodiment of the present disclosure.

Referring toFIG. 18, a mobile system900includes an application processor910, a connectivity unit920, a volatile memory device930, a nonvolatile memory device940, a user interface950and a power supply960. According to an exemplary embodiment of the present disclosure, the mobile system900may be any mobile system, such as a mobile phone, a smart phone, a personal digital assistant (PDA), a portable multimedia player (PMP), a digital camera, a portable game console, a music player, a camcorder, a video player, a navigation system, etc.

The application processor910may execute applications, such as an Internet browser, a game application, a video player application, etc. The application processor910may store a unique key911that is unique for each mobile system. When the application processor910executes a boot image stored in the nonvolatile memory device940, the application processor910may verify a message authentication code included in the boot image using the unique key911. Accordingly, confidentiality and integrity of the boot image may be maintained, and the mobile system900may perform a secure boot operation using an authenticated boot image. According to exemplary embodiments of the present disclosure, the application processor910may be coupled to an internal/external cache memory.

The connectivity unit920may communicate with an external device. For example, the connectivity unit920may perform a USB communication, an Ethernet communication, a near field communication (NFC), a radio frequency identification (RFID) communication, a mobile telecommunication, a memory card communication, etc.

The volatile memory device930may store data processed by the application processor910, or may serve as a working memory. For example, the volatile memory device930may be implemented by a DRAM, a SRAM, a mobile DRAM, or the like.

The nonvolatile memory device940may store the boot image for booting the mobile system900. The boot image may include the message authentication code as well as a digital signature. The digital signature may be verified using a public key, and the message authentication code may be verified using the unique key911. According to exemplary embodiments, the boot image may further include an update public key for updating the public key, purpose information for preventing the mobile system900from being booted by a leaked boot image for development or mass product, and/or a build number for preventing the boot image from being updated to an older boot image. For example, the nonvolatile memory device940may be implemented by an EEPROM, a flash memory, a PRAM, a RRAM, a NFGM, a PoRAM, a MRAM, a FRAM, or the like.

The user interface950may include at least one input device, such as a keypad, a touch screen, etc., and at least one output device, such as a display device, a speaker, etc. The power supply960may supply the mobile system900with power. In some embodiments, the mobile system900may further include a camera image processor (CIS), and a modem, such as a baseband chipset. For example, the modem may be a modem processor that supports at least one of various communications, such as GSM, GPRS, WCDMA, HSxPA, etc.

FIG. 19is a block diagram illustrating a computing system according to an exemplary embodiment of the present disclosure.

Referring toFIG. 19, a computing system1000includes a processor1010, an input/output hub1020, an input/output controller hub1030, at least one memory module1040, a graphic card1050, and a basic input basic output (BIOS) memory1060. According to an exemplary embodiment of the present disclosure, the computing system1000may be any computing system, such as a personal computer (PC), a server computer, a workstation, a tablet computer, a laptop computer, a mobile phone, a smart phone, a personal digital assistant (PDA), a portable multimedia player (PMP), a digital camera, a digital television, a set-top box, a music player, a portable game console, a navigation device, etc.

The processor1010may perform specific calculations or tasks. For example, the processor1010may be a microprocessor, a central process unit (CPU), a digital signal processor, or the like. The processor1010may store a unique key1011that is unique for each computing system. When the processor1010executes a boot image stored in the BIOS memory1060, the processor1010may verify a message authentication code included in the boot image using the unique key1011. Accordingly, confidentiality and integrity of the boot image may be maintained, and the computing system1000may perform a secure boot operation using an authenticated boot image. According to an exemplary embodiment of the present disclosure, the processor1010may include one processor core or multiple processor cores. For example, the processor1010may be a multi-core processor, such as a dual-core processor, a quad-core processor, a hexa-core processor, etc. AlthoughFIG. 19illustrates an example of the computing system1000including one processor1010, the computing system1000according to an exemplary embodiment of the present disclosure may include one or more processors.

The processor1010may include a memory controller (not shown) that controls an operation of the memory module1040. The memory controller included in the processor1010may be referred to as an integrated memory controller (IMC). A memory interface between the memory module1040and the memory controller may be implemented by one channel including a plurality of signal lines, or by a plurality of channels. Each channel may be coupled to at least one memory module1040. In some embodiments, the memory controller may be included in the input/output hub1020. The input/output hub1020including the memory controller may be referred to as a memory controller hub (MCH).

The input/output hub1020may manage data transfer between the processor1010and devices, such as the graphic card1050. The input/output hub1020may be coupled to the processor1010via one of various interfaces, such as a front side bus (FSB), a system bus, a HyperTransport, a lightning data transport (LDT), a QuickPath interconnect (QPI), a common system interface (CSI), etc. AlthoughFIG. 19illustrates an example of the computing system1000including one input/output hub1020, in some embodiments, the computing system1000may include a plurality of input/output hubs.

The input/output hub1020may provide various interfaces with the devices. For example, the input/output hub1020may provide an accelerated graphics port (AGP) interface, a peripheral component interface-express (PCIe), a communications streaming architecture (CSA) interface, etc.

The graphic card1050may be coupled to the input/output hub1020via the AGP or the PCIe. The graphic card1050may control a display device (not shown) for displaying an image. The graphic card1050may include an internal processor and an internal memory to process the image. In some embodiments, the input/output hub1020may include an internal graphic device along with or instead of the graphic card1050. The internal graphic device may be referred to as an integrated graphics, and an input/output hub including the memory controller and the internal graphic device may be referred to as a graphics and memory controller hub (GMCH).

The input/output controller hub1030may perform data buffering and interface arbitration to efficiently operate various system interfaces. The input/output controller hub1030may be coupled to the input/output hub1020via an internal bus. For example, the input/output controller hub1030may be coupled to the input/output hub1020via one of various interfaces, such as a direct media interface (DMI), a hub interface, an enterprise Southbridge interface (ESI), PCIe, etc. The input/output controller hub1030may provide various interfaces with peripheral devices. For example, the input/output controller hub1030may provide a universal serial bus (USB) port, a serial advanced technology attachment (SATA) port, a general purpose input/output (GPIO), a low pin count (LPC) bus, a serial peripheral interface (SPI), a PCI, a PCIe, etc.

The BIOS memory1060may be coupled to the input/output controller hub1030via the SPI or the LPC bus. The BIOS memory1060may store the boot image for booting the computing system1000. The boot image may include the message authentication code as well as a digital signature. The digital signature may be verified using a public key, and the message authentication code may be verified using the unique key1011. According to an exemplary embodiment of the present disclosure, the boot image may further include an update public key for updating the public key, purpose information for preventing the mobile system1000from being booted by a leaked boot image for development or mass product, and/or a build number for preventing the boot image from being updated to an older boot image.

In some embodiments, the processor1010, the input/output hub1020and the input/output controller hub1030may be implemented as separate chipsets or separate integrated circuits. In other embodiments, at least two of the processor1010, the input/output hub1020and the input/output controller hub1030may be implemented as one chipset.

The foregoing is illustrative of exemplary embodiments and is not to be construed as limiting thereof. Although a few exemplary embodiments have been described, those skilled in the art will readily appreciate that many modifications are possible in exemplary embodiments described herein without materially departing from the novel teachings and advantages of the inventive concepts. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the claims. Therefore, it is to be understood that the foregoing is illustrative of various exemplary embodiments and is not to be construed as limited to specifically disclosed exemplary embodiments, and that modifications to disclosed exemplary embodiments, as well as other exemplary embodiments, are intended to be included within the scope of the appended claims.