System and method for authentication of software

Abstract

Systems and methods for authentication of software are provided. The system includes a processing circuitry and a system memory configured to store at least one software image. The at least one software image includes at least one program image and a keychain image associated with the at least one software image, the keychain image including at least one soft key. The processing circuitry is configured to obtain, based on key information included in the at least one software image, a desired soft key associated with the at least one software image from the keychain image, and authenticate the at least one software image based on the obtained soft key.

Description

[0001] This application claims the benefit of priority to Korean Patent Application No. 10-2020-0002691, filed on January 8, 2020, in the Korean Intellectual Property Office, the disclosure of which is incorporated herein in its entirety by reference. TECHNICAL FIELD

[0002] Various example embodiments of inventive concepts relate to system security, and more particularly, to an apparatus, system, non-transitory computer readable medium, and / or method for authentication of software. BACKGROUND

[0003] Attacks on a system including software and hardware can be attempted in various ways. For example, an attacker can disassemble the system and extract desired information from the disassembled system. Also, the attacker can change at least a portion of software of the system and enable the system to perform an operation intended by the attacker. Although various types of system security techniques can be employed to protect a system or data stored in the system from advanced attacks, the system security techniques can cause an overhead to the manufacturing, operation, expansion, and cost of the system. Accordingly, it is desirable and / or necessary to have a system security technique capable of protecting a system from advanced attacks while reducing and / or minimizing the overhead. SUMMARY

[0004] Various example embodiments of inventive concepts provide an apparatus, system, non-transitory computer readable medium, and / or method for secure and efficient authentication of software.

[0005] According to an aspect of at least one example embodiment of inventive concepts, a system is provided that includes a system memory configured to store at least one software image including at least a program image and a keychain image associated with the at least one software image, the keychain image including at least one soft key. The system can also include a processing circuit configured to obtain a desired soft key associated with the at least one software image from the keychain image based on key information included in the at least one software image, and authenticate the at least one software image based on the obtained soft key.

[0006] According to another aspect of at least one example embodiment of inventive concepts, a method of authenticating a software image loaded in a system memory is provided. The method is performed by a processing circuit. The method includes authenticating a first software image including first key information and at least one soft key, and authenticating a second software image including second key information, the step of authenticating the second software image including obtaining the second key information from the second software image, obtaining the first soft key from the authenticated first software image based on the second key information, and verifying a digital signature of the second software image based on the first soft key.

[0007] According to another aspect of at least one of the example embodiments of the inventive concepts, there is provided a method of generating a signed software image to perform authentication of software in a system, the system comprising processing circuitry. The method comprises generating a program image as a signed software image, the program image to be executed by the system; and generating a keychain image as a signed software image, the keychain image comprising at least one soft key, the step of generating the keychain image comprising obtaining a first binary image, the first binary image comprising computer readable instructions, generating a first signature, the first signature to be verified based on a first soft key, and generating the program image of the first signature, the program image of the first signature comprising the first binary image and the first signature. BRIEF DESCRIPTION OF DRAWINGS

[0008] The various example embodiments of the inventive concepts will be more fully understood from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0009] Figure 1 is a block diagram of an example of a system according to at least one example embodiment;

[0010] Figure 2 is a diagram of an example of a system memory configured to store a software image according to at least one example embodiment;

[0011] Figure 3 is a diagram of an example of a structure of a keychain image according to at least one example embodiment;

[0012] Figure 4 is a flowchart of an example of a method of authenticating software according to at least one example embodiment;

[0013] Figure 5 is a flowchart of an example of a method of authenticating software according to at least one example embodiment;

[0014] Figure 6A and Figure 6B is a block diagram of an example of an operation of obtaining a hard key according to some example embodiments;

[0015] Figure 7 is a flowchart of an example of a method of authenticating software according to at least one example embodiment;

[0016] Figure 8 is a diagram of an example of an operation of authenticating a software image according to at least one example embodiment;

[0017] Figure 9 is a diagram of an example of an operation of authenticating a software image according to at least one example embodiment;

[0018] Figure 10 is a diagram of an example of an operation of authenticating a software image according to at least one example embodiment;

[0019] Figure 11 is a block diagram of an example of an image signing system according to at least one example embodiment;

[0020] Figure 12 is a flowchart of an example of a method of authenticating software according to at least one example embodiment;

[0021] Figure 13 is a flowchart of an example of a method of authenticating software according to at least one example embodiment; and

[0022] Figure 14 is a flowchart of a method of authenticating software according to at least one example embodiment. DETAILED DESCRIPTION

[0023] Figure 1 is a block diagram of an example of a system (e.g., a system for authentication of software) 10 according to at least one example embodiment. In some example embodiments, a non-limiting example of the system 10 can include a fixed computing system (e.g., a server, a desktop computer, and / or a kiosk, etc.) or a subsystem thereof. In some example embodiments, a non-limiting example of the system 10 can include a portable computing system (e.g., a mobile phone, a wearable device, a smart device, a game console, a tablet computer, and / or a laptop computer, etc.) and a subsystem thereof. In some example embodiments, a non-limiting example of the system 10 can include a subsystem (such as a home appliance, an Internet of Things (IoT) device, an industrial equipment, and / or a transportation vehicle, etc.) included in any system different from a standalone computing system.

[0024] Referring to Figure 1 , the system 10 can include at least one processor 12, a system memory 14, and / or a system storage 16, etc., but example embodiments are not limited thereto. For example, in other example embodiments, there can be two or more processors, system memories, system storages, and / or other system components, etc. In some example embodiments, each of the processor 12, the system memory 14, and the system storage 16 can be manufactured using a semiconductor process, and at least two of the processor 12, the system memory 14, and the system storage 16 can be included in the same package. In some example embodiments, the processor 12, the system memory 14, and the system storage 16 can be mounted on a board and connected to each other through a pattern formed on the board.

[0025] The processor 12 can include at least one core 12_1, a random access memory (RAM) 12_2, a read only memory (ROM) 12_3, a secure memory 12_4, a memory controller 12_5, and / or a storage controller 12_6, although example embodiments are not limited thereto. According to at least one example embodiment, the processor 12 can be referred to as processing circuitry, and can include hardware such as a logic circuit, a hardware / software combination such as at least one processor core executing software and / or executing any instruction set, or a combination thereof. For example, the processing circuitry can more specifically include, but is not limited to, a central processing unit (CPU), an arithmetic logic unit (ALU), a digital signal processor (DSP), a graphics processing unit (GPU), a communication processing (CP), a microcomputer, a field programmable gate array (FPGA), a system on chip (SoC), a programmable logic unit, a microprocessor, an application specific integrated circuit (ASIC), and the like, and according to some example embodiments, the processing circuitry can further include one or more of an interface, a bus, a memory, and / or a controller, and the like. In some embodiments, at least two of the at least one core 12_1, the random access memory (RAM) 12_2, the read only memory (ROM) 12_3, the secure memory 12_4, the memory controller 12_5, and the storage controller 12_6 can communicate with each other. For example, the processor 12 can access the system memory 14 by using the memory controller 12_5 configured to provide an interface for accessing the system memory 14. Also, the processor 12 can access the system storage 16 by using the storage controller 12_6 configured to provide an interface for accessing the system storage 16. In some example embodiments, the processor 12 can further include at least one bus through which the at least one core 12_1, the RAM 12_2, the ROM 12_3, the secure memory 12_4, the memory controller 12_5, and / or the storage controller 12_6, or a combination or sub-combination thereof, are connected. In some example embodiments, the processor 12 can further include a hardware accelerator designed to perform a desired and / or predefined operation at a high speed, and an input / output (I / O) interface configured to provide a communication path between the processor 12 and external components thereof. In some example embodiments, the components of the processor 12 can be integrated in a single chip or a single die, and the processor 12 can be referred to as a system on chip (SoC). In some example embodiments, the components of the processor 12 can be integrated in at least two chips included in one package, and the processor 12 can be referred to as a system in package (SiP). In some example embodiments, the processor 12 can also be referred to as an application processor, and the like, but is not limited thereto.

[0026] The at least one core 12_1 can represent any processing element configured to execute instructions (e.g., computer-readable instructions and / or machine-executable instructions, etc.). In some example embodiments, the at least one core 12_1 can execute instructions included in a program image, which is a software image stored in the system memory 14. For example, at least some of the instructions included in the program image stored in the system memory 14 can be copied to a memory of the processor 12 (e.g., the RAM 12_2 or a cache included in the at least one core 12_1), and the at least one core 12_1 can execute the copied instructions, although example embodiments are not limited as such. In some example embodiments, the at least one core 12_1 can include a plurality of homogeneous cores and / or a plurality of heterogeneous cores, each of which can independently execute instructions. For example, each of the plurality of homogeneous cores and / or the plurality of heterogeneous cores can include a low-performance processor and / or a high-performance processor, or a non-secure processor and / or a secure processor, etc.

[0027] The RAM 12_2 can store (e.g., temporarily store) data used by the at least one core 12_1 and / or another component of the processor 12. For example, the RAM 12_2 can temporarily store data read from the system memory 14 and / or the system storage 16, and / or temporarily store data to be written to the system memory 14 and / or the system storage 16. Also, the RAM 12_2 can temporarily store instructions executed by the at least one core 12_1. In some example embodiments, the RAM 12_2 can include a volatile memory (e.g., a static RAM (SRAM), etc.) that operates at a relatively high speed.

[0028] The ROM 12_3 can store a program image executed by the at least one core 12_1 in a non-volatile manner. For example, as shown in FIG. 1B, the ROM 12_3 can store a boot program IMG0 including instructions (e.g., computer-readable instructions, etc.), but is not limited thereto, where the instructions (e.g., computer-readable instructions, etc.) are first executed by the at least one core 12_1 when a supply of power to the processor 12 is initialized or the processor 12 is reset. The ROM 12_3 can be referred to as a boot ROM. In some example embodiments, the ROM 12_3 can also store data (e.g., read-only data, etc.) that is immutable during execution of the instructions by the at least one core 12_1. Figure 1

[0029] ​The secure memory 12_4 can store data (e.g., unique data, etc.) of the processor 12 in a non-volatile manner. In some example embodiments, the secure memory 12_4 can store data including at least one hardware key or a digest thereof, etc., which is used for encrypting and / or decrypting data in the processor 12 and has a unique value (e.g., a unique identifier corresponding to the processor 12, a unique value associated with the processor 12, etc.) of the processor 12. For example, the digest can be used to verify the key. As used herein, a digest can mean information obtained based on an algorithm, which is cryptographically verified from source information to verify the source information. The digests corresponding to different source information can also be different from each other. For example, the digest of the hardware key can mean a hash obtained from the hardware key based on a hash algorithm (e.g., a Secure Hash Algorithm (SHA), etc.), but example embodiments are not limited thereto, and other methods of generating a digest from a hardware key can be used. In some example embodiments, the secure memory 12_4 can store information for authenticating a software image loaded in the system memory 14. For example, as described below with reference to Figure 6A the secure memory 12_4 can store a key and / or a digest (e.g., a hash) of the key for verifying a signature (e.g., a digital signature, an electronic signature, etc.) included in the software image. As used herein, the key or the digest thereof stored in the processor 12 and used for verifying the signature included in the software image can be referred to as a hard key or a device key, and the processor 12 can be referred to as including the hard key. In some example embodiments, the secure memory 12_4 can include a One Time Programmable (OTP) memory such as an anti-fuse array, but is not limited thereto. In some example embodiments, the above-described hard key can be stored in the ROM 12_3. For example, as described below with reference to Figure 6B the hard key can be included in the boot program IMG0 or stored independently in a region of the ROM 12_3 different from a region corresponding to the boot program IMG0, but example embodiments are not limited thereto. In some example embodiments, the processor 12 can obtain at least one hard key from a software image loaded in the system memory.

[0030] The system memory 14 can store at least one software image, but is not limited thereto. In some example embodiments, non-limiting examples of the system memory 14 can include volatile memory devices such as dynamic random access memory (DRAM) and / or static RAM (SRAM), etc. In some example embodiments, non-limiting examples of the system memory 14 can include non-volatile memory devices such as flash memory, electrically erasable programmable read only memory (EEPROM), silicon-oxide-nitride-oxide-silicon (SONOS) memory, polymer memory, magnetic RAM (MRAM), phase change RAM (PRAM), and / or resistive RAM (RRAM), etc.

[0031] The processor 12 can execute program codes (e.g., computer readable instructions, machine readable instructions, etc.) included in at least one software image stored in the ROM 12_3 and / or load at least one software image stored in the system storage 16 into the system memory 14, etc., and execute the loaded program codes. For example, a boot program IMG0 stored in the ROM 12_3 can be executed by the at least one core 12_1, and thus, a first software image IMG1 can be loaded from the system storage 16 into the system memory 14. Further, the first software image IMG1 (i.e., instructions included in the first software image IMG1) can be executed by the at least one core 12_1, and thus, a second software image IMG2 can be loaded from the system storage 16 into the system memory 14. Similarly, a third software image IMG3 can be loaded into the system memory 14, etc., but example embodiments are not limited thereto, and a greater or lesser number of software images can be loaded into the system memory 14. In some example embodiments, at least one software image (e.g., the first software image IMG1 and the second software image IMG2, etc.) loaded into the system memory 14 after the boot program IMG0 can also be referred to as a boot program. As used herein, when the at least one core 12_1 is referred to as performing an operation by executing instructions included in a software image, the processor 12 can be interpreted as performing a corresponding operation by executing the software image, or the processor 12 can simply be interpreted as performing a corresponding operation of the software image and / or a corresponding operation included in the software image.

[0032] An attacker can attempt to break into system 10 by altering the software images loaded in system memory 14 and / or loading altered software images into system memory 14, for example. Accordingly, system 10 can authenticate (e.g., verify, etc.) the software images loaded in system memory 14 before the software images are used, and use the authenticated software images. Authentication of a software image can include determining the reliability of the software image, and can indicate that the software image has been generated by an authenticated entity. Accordingly, a software image that is authenticated on system 10 can represent a reliable software image that has been generated and / or obtained from an authenticated entity, a verified software image, etc. For example, boot program IMG0 can authenticate first software image IMG1 after first software image IMG1 is loaded into system memory 14. Processor 12 can execute authenticated first software image IMG1. Similarly, authenticated first software image IMG1 can authenticate second software image IMG2, and authenticated second software image IMG2 can authenticate third software image IMG3, etc., although example embodiments are not limited in this respect. In some example embodiments, boot program IMG0 can authenticate second software image IMG2 or third software image IMG3, and authenticated first software image IMG1 can authenticate third software image IMG3, etc., or in other words, each software image can be authenticated by boot program IMG0 and / or a previously authenticated software image. Accordingly, the process of loading, authenticating, and executing software images can be referred to as secure booting. In some example embodiments, software images that are not successfully authenticated are not executed by system 10 (e.g., software images that are not properly authenticated and / or verified are prohibited from being executed by system 10 and / or processor 12, etc.).

[0033] As described above, the hard keys can be used as information for authenticating software images. Various software images can be used in the system 10 (i.e., executable by the processor 12) and generated by a plurality of subjects. For example, a manufacturer of the processor 12, a manufacturer of the system 10, a provider of the system 10, an administrator of the system 10, a software provider, etc. can generate software images stored in the system memory 14. Authenticating various software images generated by a plurality of subjects as described above by using the hard keys included in the processor 12 can not only limit and / or reduce unauthorized and / or modified software images generated by various subjects, but also limit and / or reduce exposure of the hard keys or private keys from which the hard keys are derived. Further, the processor 12 can include a limited number of hard keys, and thus, it can not be easy and / or more difficult to modify the hard keys stored in the secure memory 12_4 and / or the ROM 12_3 later. Further, continuous authentication of software images updated and / or newly installed in the system 10 using the limited hard keys during maintenance of the system 10 can not only involve continuously managing private keys from which the hard keys are derived, but also can cause unwanted and / or undesirable exposure of the hard keys, thereby increasing the risk of exposing the hard keys to malicious parties.

[0034] As described below with reference to the accompanying drawings, an improved system security method capable of protecting a system from advanced attacks according to at least one example embodiment can include causing a software image to be loaded in a system memory 14, the software image including not only a program image containing instructions (e.g., computer readable instructions, etc.) executed by a processor 12, but also a key chain image containing at least one key (and / or a digest thereof) for authenticating the software image. In some example embodiments, the key chain image can also be referred to as a key store image. According to at least one example embodiment, the system 10 can not only authenticate the program image, but also authenticate the key chain image, and thus, the key used for authenticating the software image can be securely extended using the authenticated key chain image. As a result, problems caused by limiting authentication of software images to hard keys can be resolved, and the risk of exposing one or more hard keys can be reduced and / or decreased. As used herein, a key or a digest thereof included in the key chain image and used for authenticating the software image can be referred to as a soft key, and the key chain image can be referred to as including at least one soft key, but is not limited thereto. The program image and the key chain image will be described below with reference to Figure 2 The program image and the key chain image are described.

[0035] According to some example embodiments, the system storage 16 does not lose data stored therein even if power supply to the system 10 is interrupted. For example, the system storage 16 can include a non-volatile memory device and / or a storage medium such as a magnetic tape, a magnetic disk, and / or an optical disk, etc. The processor 12 can process data stored in the system storage 16 or generate data and store the data in the system storage 16. Also, the processor 12 can load a software image stored in the system storage 16 into the system memory 14.

[0036] Figure 2 is a diagram of an example of the system memory 20 configured to store a software image according to at least one example embodiment. As shown in Figure 2 , the system memory 20 can store, for example, a first software image IMG1 and a second software image IMG2, but is not limited thereto. The software images stored in the system memory 20 can be dynamically changed, Figure 2 shows a state of the system memory 20 at a specific point in time. For example, the system memory 20 can store at least two software images at the same time, and at least one of the first software image IMG1 and the second software image IMG2 can be replaced or invalidated due to loading of a new software image, but example embodiments are not limited thereto, and the number of software images stored in the system memory 20 can be greater than or less than two. Hereinafter, the Figure 1 will be described. Figure 2 .

[0037] The system memory 20 can store at least one program image and at least one keychain image, etc. as one or more software images, but is not limited thereto. For example, as shown in Figure 2 , the first software image IMG1 as a program image can include a binary image BIN, first key information KNF1, and / or a first digital signature SIG1, etc., but example embodiments are not limited thereto. Also, the second software image IMG2 as a keychain image can include a keychain KCH, second key information KNF2, and / or a second digital signature SIG2, etc. In some example embodiments, as shown in Figure 2 , the program image and the keychain image can have the same structure and can be generated by a common system as described below with reference to Figure 11 , but example embodiments are not limited thereto, and according to other example embodiments, the program image and the keychain image can be generated using different systems and / or can have different structures.

[0038] The binary image BIN included in the first software image IMG1 can include a series of instructions (e.g., computer-readable instructions) to be executed by the at least one core 12_1. For example, the binary image BIN can be generated by compiling and / or interpreting source code written in a programming language. In some example embodiments, the binary image BIN can include not only instructions but also data referenced by, associated with, and / or used by the instructions. The binary image BIN can be referred to as binary data, binary code, binary code image, etc.

[0039] The key chain KCH included in the second software image IMG2 can include at least one soft key, but is not limited thereto. For example, the key chain KCH can include a plurality of soft keys or digests thereof for authenticating software images and different from the second software image IMG2. An example of the key chain KCH will be described below with reference to Figure 3 An example of the key chain KCH is described.

[0040] Both the program image and the key chain image can include key information. The key information can be information related to a key for authenticating a software image (e.g., a corresponding software image, an associated software image, etc.). For example, the first key information KNF1 can indicate information related to a key for authentication of the first software image IMG1, the second key information KNF2 can indicate information related to a key for authentication of the second software image IMG2, etc. The key information can include a value indicating a hard key or a soft key (e.g., a value indicating whether a hard key type or a soft key type is to be used for authenticating the corresponding software image, etc.), and can also include a key index for identifying one of a plurality of hard keys and / or a plurality of soft keys (e.g., the key index is to identify a desired and / or specific hard key or soft key to be used for performing authentication / verification of the corresponding software image, etc.).

[0041] Both the program image and the keychain image can include a digital signature, but example embodiments are not limited thereto, and a single digital signature can be used for both the program image and the associated keychain image. The digital signature for authenticating the software image (i.e., verifying the reliability of the software image) can be verified by a key, and the successfully verified software image can be referred to as an authenticated software image. For example, the first digital signature SIG1 included in the first software image IMG1 can be verified based on the first key information KNF1 by a hard key stored in the processor 12 or a soft key included in the keychain image. Also, the second digital signature SIG2 included in the second software image IMG2 can be verified based on the second key information KNF2 by a hard key stored in the processor 12 or a soft key included in the keychain image. The software image including a signature, such as the first software image IMG1 and the second software image IMG2, can be referred to as a signed software image. As used herein, a signed software image can be simply referred to as a software image. Hereinafter, a description will be made with reference to Figures 11 to 14 Examples of a method of generating a software image are described, but example embodiments are not limited thereto.

[0042] Figure 3 FIG. 1 is a diagram of an example of a structure of a keychain image 30 according to at least one example embodiment. The keychain image 30 can include a keychain KCH, key information KNF, and / or a digital signature SIG as described above with reference to FIG. 1, and can further include a header HEA, but example embodiments are not limited thereto. In some example embodiments, the keychain image can have a structure arranged in a different manner from that shown in FIG. 1, the keychain image can include only some of the components shown in FIG. 1, or the keychain image can further include additional components not shown in FIG. 1. Hereinafter, a description of the structure identical to that shown in FIG. 1 will be omitted. Figure 2 Figure 3 Figure 3 Figure 3 Figure 2

[0043] The header HEA can include information about the keychain image 30. For example, a non-limiting example of the header HEA can include at least one of an identifier indicating the keychain image 30, a version of the keychain image 30, a length of the header HEA, a number of soft keys included in the keychain KCH, generation information (e.g., a generation date and / or a generator) of the keychain image 30, and / or a length of valid data (e.g., the meta area META and the key area KEYS) included in the keychain KCH, but example embodiments are not limited thereto. The processor 12 and / or a software developer can identify the keychain image 30 and / or the associated software image based on the information included in the header HEA.

[0044] ​​​​​The key chain KCH can include a meta area META, a key area KEYS, and / or a zero padding area ZPD, etc., but is not limited thereto. The meta area META can include meta data related to the soft keys included in the key area KEYS (e.g., the meta data can correspond to and / or can be associated with the soft keys included in the key area KEYS, etc.). For example, as shown in Figure 3 FIG. 1A, the meta area META can include a first meta data segment MET1 to an n-th meta data segment METn (here, n is an integer greater than 0) corresponding to a first soft key KEY1 S to an n-th soft key KEYn S included in the key area KEYS. The meta data can include information about the soft key to which it corresponds. For example, non-limiting examples of the meta data can include at least one of a name of the soft key, group information to which the soft key belongs, information related to a software image to be authenticated by the soft key (e.g., software image information, etc.), and / or an identifier of the soft key (e.g., a unique identifier of the soft key), etc. The key area KEYS can include at least one soft key. For example, as shown in Figure 3 FIG. 1A, the key area KEYS can include a first soft key KEY1 S to an n-th soft key KEYn S As described above, the soft keys included in the key area KEYS can be used to verify a digital signature included in a software image. In some example embodiments, the soft keys included in the key area KEYS can be public keys generated together with a private key and / or based on the private key, or a digest (e.g., a hash, etc.) of the public key. The zero padding area ZPD can have a variable length according to the number of soft keys included in the key chain KCH and / or the length of the soft keys included in the key chain KCH. The zero padding area ZPD can include arbitrary data (e.g., all-zero data, all-one data, randomly generated data, etc.).

[0045] As described above with reference to Figure 2 , the key information KNF can include information related to a key (e.g., a signature key, etc.) used to authenticate the key chain image 30 (i.e., a signature key used to verify the digital signature SIG). Further, as described above with reference to Figure 2 , the digital signature SIG can be verified by the key (e.g., the signature key) specified by the key information KNF, and the key chain image 30 can be authenticated when the verification of the digital signature SIG is successful.

[0046] Figure 4 is a flowchart of an example of a method of authenticating software according to at least one example embodiment. Specifically, Figure 4 the flowchart of FIG. 1B illustrates a method of authenticating a software image. In some example embodiments, Figure 4 the method of FIG. 1B can be performed byFigure 1 The example implementation is executed by system 10, but the example embodiment is not limited thereto; other hardware can be used to perform the operations of the example method. For example, software image authentication can be performed via bootloader IMG0 or a previously authenticated software image (i.e., a program image). Methods for authenticating software images may include, for example... Figure 4 The multiple operations S50, S70, and S90 shown are assumed to be performed by... Figure 1 Processor 12 executes the commands, but is not limited to this. See also... Figure 1 describe Figure 4 The method shown in the figure.

[0047] In some example embodiments, in Figure 4 The authentication software image method shown can be executed by a security processor (e.g., a dedicated security processing circuit, etc.). For example, as in an integrated circuit (IC) including both a security processor and a non-security processor (which has already been disclosed in Korean Patent Application No. 10-2020-0002692, entitled "Apparatus and Method for Securely Managing Keys," filed by the applicant on the same date as this application with the Korean Intellectual Property Office, the disclosure of which is incorporated herein by reference in its entirety), Figure 1 Processor 12 may include secure processors and non-secure processors, in Figure 4 The method of authenticating the software image shown can be executed by a security processor included in processor 12.

[0048] In operation S50, the operation of obtaining key information and / or digital signatures of the software image can be performed. For example, processor 12 can read key information and / or digital signatures included in the software image from system memory 14. In some example embodiments, with Figure 4 The differences shown are that operation S70 can be followed by an operation to obtain a digital signature, or in other words, key information can be obtained at a time separate from the digital signature and / or during a read operation separate from the digital signature.

[0049] In operation S70, an operation to obtain a hard key or a soft key can be performed. For example, processor 12 can determine whether the key used to authenticate the software image is a hard key or a soft key based on the key information obtained in operation S50, and can obtain the hard key or the soft key based on the determination result. The following will refer to... Figure 5 Describe an example of operation S70.

[0050] In operation S90, an operation of verifying the digital signature can be performed. For example, the processor 12 can verify the digital signature, which can be obtained, for example, in operation S50, by using the key obtained in operation S70. In some example embodiments, the key obtained in operation S70 (i.e., the hard key or the soft key) can correspond to a public key (or a digest of the public key) in a key pair including a private key and the public key, and the digital signature can be derived from and / or generated using the private key, but example embodiments are not limited thereto. Thus, when the software image is generated by an authenticated entity, the digital signature can be successfully verified based on the hard key or the soft key.

[0051] Figure 5 is a flowchart of an example of a method of authenticating software according to at least one example embodiment. Specifically, Figure 5 the flowchart of Figure 4 operation S70. As described above with reference to Figure 4 operation S70 of Figure 5 operation S70' of Figure 5 may include a plurality of operations S72, S74, and S76. Hereinafter, the flowchart of Figure 1 will be described with reference to Figure 5 .

[0052] In operation S72, an operation of determining a key type can be performed. For example, the processor 12 can determine whether to obtain a hard key or a soft key based on a value indicating the key type included in the key information. As shown in Figure 5 operation S74, when the key information includes a value indicating a hard key (e.g., the value indicates that a hard key type is used), an operation of obtaining a hard key can be performed in operation S74, but example embodiments are not limited thereto. In some example embodiments, the key information can include a key type field which can contain a value indicating a hard key or a soft key. In some example embodiments, the processor 12 can include a plurality of hard keys. The key information can include a key index for identifying a desired hard key from among the plurality of hard keys, and the processor 12 can obtain the desired hard key from among the plurality of hard keys based on the key index. Examples of the operation of obtaining a hard key in operation S74 will be described below with reference to Figure 6A and Figure 6B .

[0053] As another example, when the key information includes a value indicating a soft key (e.g., the value indicating the type of soft key used), an operation to obtain the soft key corresponding to the key index can be performed in operation S76. For example, processor 12 can extract the key index included in the key information and obtain the desired soft key corresponding to the key index from among a plurality of soft keys included in the key chain mirror. The key index may include any information capable of identifying the desired soft key in the key chain mirror. For example, the key index may include a region of the key chain mirror where the soft key is stored (or, for example,...) Figure 3 The address offset of the key chain (KCH). Furthermore, the key index may include an identifier capable of identifying the soft key (e.g., a non-cryptographic hash of the soft key, a "checksum," or a cyclic redundancy check (CRC) and / or a search key generated by any algorithm used to generate the search key, etc.), but the example embodiment is not limited thereto. The following will refer to... Figure 7 Describe an example of operation S76.

[0054] Figure 6A and Figure 6B This is a block diagram illustrating an example of the operation of obtaining a hard key according to some example embodiments. (Refer to the above...) Figure 5 The statement states that when the key information (e.g., key type information) included in the software image includes a value indicating the hard key (e.g., a value indicating the type of hard key used), Figure 1 The processor 12 can obtain the hard key KEY based on the key type information. H . (to be omitted) Figure 6A and Figure 6B The description of the same aspects as those given above with reference to the accompanying drawings previously discussed.

[0055] Reference Figure 6A Hard key KEY H It can be stored in secure memory 64a, but the example embodiments are not limited thereto. For example, such as Figure 6A As shown, the processor 60a (e.g., processing circuitry, etc.) may include at least one core 62a and a secure memory 64a, and the secure memory 64a may store a hard key KEY. H At least one core 62a (i.e., the program image is loaded into and executed by at least one core 62a, and at least one core 62a is allowed to perform software authentication of at least one example embodiment) can access secure memory 64a and obtain the hard key KEY. H In some example implementations, the hard key KEY H The processor 60a can be programmed into the non-rewritable, non-volatile memory included in the secure memory 64a during the manufacturing process, but the example embodiments are not limited thereto. In some example embodiments, the secure memory 64a may store a hard key KEY.H Multiple hard keys are used, but the example implementation is not limited to this.

[0056] Reference Figure 6B According to other example embodiments, the hard key KEY H It can be included in the program image. For example, such as Figure 6B As shown, the bootloader BL may include a binary image (BIN), key information (KNF), and a digital signature (SIG), and can be loaded as a program image into system memory (60b). Hard key (KEY) H This can be included in the binary image BIN of the bootloader BL. Therefore, the processor and / or processing circuitry (such as...) Figure 1 The program image of the processor 12) or the processor being loaded into and executed by the processor, thereby transforming the processor into a processor for performing software authentication of at least one example embodiment, can access the boot program BL stored in system memory 60b and obtain the hard key KEY. H .

[0057] Figure 7 This is a flowchart illustrating an example of a method for authentication software according to at least one example embodiment. Specifically, Figure 7 The flowchart shows Figure 5 Example of operation S76. See above for reference. Figure 5 As mentioned above, it is possible to Figure 7 In operation S76', the operation to obtain the soft key corresponding to the key index is performed. For example... Figure 7 As shown, operation S76' may include operations S76_2 and S76_4. In the following text, operations S76_2 and S76_4 will be included... Figure 3 The first soft key KEY1 in keychain mirror 30 S Up to the nth soft key KEYn S Description of one of the obtained assumptions Figure 7 However, the example embodiments are not limited thereto. Reference will be made to... Figure 1 and Figure 3 describe Figure 7 The flowchart is shown, but the example embodiment is not limited thereto.

[0058] In operation S76_2, an operation can be performed to obtain the identifier of the soft key included in the key chain. For example, processor 12 can obtain the first soft key KEY1 included in the key chain KCH of key chain mirror 30. S Up to the nth soft key KEYn S The identifier. In some example embodiments, the first metadata fragment MET1 to the nth metadata fragment METn may each include a first soft key KEY1. S Up to the nth soft key KEYn SThe processor 12 can obtain the identifier from the first metadata fragment MET1 to the nth metadata fragment METn. In some example embodiments, the processor 12 can obtain the identifier from the first soft key KEY1. S Up to the nth soft key KEYn S An identifier is generated, but the example embodiments are not limited thereto. In some example embodiments, as referred to... Figure 10 The processor 12 can obtain the identifier of the soft key included in multiple key chain mirrors.

[0059] In operation S76_4, an operation can be performed to obtain a soft key corresponding to an identifier that matches the same key index (e.g., a desired key identifier, etc.). For example, the key index included in the key information can be an identifier of the soft key, and the processor 12 can determine the identifier that matches the key index from the identifiers obtained in operation S76_2, and obtain the soft key corresponding to the determined identifier.

[0060] Figure 8 This is an illustration of an example of the operation of an authentication software image based on at least one example embodiment. Specifically, Figure 8 This illustrates the process during the processing of the certified software image. Figure 1 The system memory 14 is in its first states 81 to fifth states 85, but the example embodiment is not limited thereto. In the following text, reference will be made to... Figure 1 describe Figure 8 However, the example embodiments are not limited thereto.

[0061] In the first state 81, the system memory 14 may store the first software image IMG1 as an authenticated program image. For example, the first software image IMG1 may be authenticated by a program image loaded in the system memory 14 before the first software image IMG1 is loaded, and / or by a boot program IMG0 stored in ROM 12_3, but the example embodiment is not limited thereto.

[0062] In the second state 82, the second software image IMG2 can be loaded into the system memory 14 as a program image. For example, the authenticated first software image IMG1 can load the second software image IMG2 from the system storage device 16 into the system memory 14, and an attempt can be made to authenticate the loaded second software image IMG2. However, the example embodiment is not limited to this. For example, the second software image IMG2 can be authenticated by the bootloader IMG0, etc.

[0063] In the third state 83, the second software image IMG2 can be authenticated, and the third software image IMG3 can be loaded into the system memory 14 as a keychain image. For example, the second software image IMG2 can be authenticated using a hard key based on key information associated with the second software image IMG2, but example embodiments are not limited thereto. Also, the authenticated first software image IMG1 or the authenticated second software image IMG2 can load the third software image IMG3 from the system storage 16 into the system memory 14, and attempt to authenticate the loaded third software image IMG3, etc.

[0064] In the fourth state 84, the third software image IMG3 can be authenticated, and the fourth software image IMG4 can be loaded into the system memory 14 as a program image. For example, the third software image IMG3 can be authenticated using a hard key or a soft key based on key information associated with the third software image IMG3, etc. Also, the authenticated first software image IMG1 or the authenticated second software image IMG2 can load the fourth software image IMG4 from the system storage 16 into the system memory 14, and can attempt to authenticate the loaded fourth software image IMG4, etc.

[0065] In the fifth state 85, the fourth software image IMG4 can be authenticated. For example, the fourth software image IMG4 can be authenticated using a hard key or a soft key included in the third software image IMG3 based on key information associated with the fourth software image IMG4, etc. Accordingly, the system memory 14 can sequentially store authenticated software images, and the processor 12 can execute a program image among the stored software images. However, example embodiments are not limited thereto, and the number of software images stored in the system memory 14 can be greater than or less than four, etc.

[0066] Figure 9 is a diagram of an example of an operation of authenticating software images according to at least one example embodiment. Specifically, Figure 9 shows a state of a system memory 14 during an operation of authenticating software images Figure 1 of the system memory 14. Hereinafter, the operation of authenticating software images will be described with reference to Figure 1 . Figure 9 .

[0067] Referring to Figure 9 , in the first state 91, the system memory 14 can store the first software image IMG1 as an authenticated program image. For example, the first software image IMG1 can be authenticated by a program image loaded in the system memory 14 before the first software image IMG1 is loaded, and / or can be authenticated by a boot program IMG0 stored in the ROM 12_3, but example embodiments are not limited thereto.

[0068] In the second state 92, the second software image IMG2 can be loaded into the system memory 14 as a keychain image. For example, the authenticated first software image IMG1 can load the second software image IMG2 from the system storage 16 into the system memory 14, and can attempt to authenticate the loaded second software image IMG2, etc.

[0069] In the third state 93, the second software image IMG2 can be authenticated, and the third software image IMG3 can be loaded into the system memory 14 as a program image. For example, the second software image IMG2 can be authenticated using a hard key based on key information associated with the second software image IMG2. Also, the authenticated first software image IMG1 can load the third software image IMG3 from the system storage 16 into the system memory 14 as a program image, and can attempt to authenticate the loaded third software image IMG3.

[0070] In the fourth state 94, the third software image IMG3 can be authenticated, and the fourth software image IMG4 can be loaded into the system memory 14 as a keychain image. For example, the third software image IMG3 can be authenticated using a hard key or a soft key based on key information associated with the third software image IMG3, etc. When the key information of the third software image IMG3 indicates a desired soft key, for example, the desired soft key associated with the third software image IMG3 included in the second software image IMG2 can be identified, and the third software image IMG3 can be authenticated using the desired soft key (e.g., the identified soft key). Also, the authenticated first software image IMG1 or the authenticated third software image IMG3 can load the fourth software image IMG4 from the system storage 16 into the system memory 14 as a keychain image, and can attempt to authenticate the loaded fourth software image IMG4.

[0071] In the fifth state 95, the fourth software image IMG4 can be authenticated. For example, the fourth software image IMG4 can be authenticated using a hard key or a soft key based on key information associated with the fourth software image IMG4. When the key information of the fourth software image IMG4 indicates a desired soft key, for example, the desired soft key associated with the fourth software image IMG4 included in the second software image IMG2 can be identified, and the fourth software image IMG4 can be authenticated using the desired soft key (e.g., the identified soft key).

[0072] Figure 10 is a diagram illustrating an example of an operation of authenticating software images according to at least one example embodiment. Specifically, Figure 10 illustrates a first state 101 to a third state 103 of a system memory 14 during an operation of authenticating software images. Figure 1 illustrates a first state 101 to a third state 103 of a system memory 14 during an operation of authenticating software images. Figure 1describe Figure 10 However, the example embodiments are not limited thereto.

[0073] Reference Figure 10 In the first state 101, the system memory 14 can store a first software image IMG1 as an authentication key chain image, a second software image IMG2 as an authentication key chain image, and a third program image IMG3 as an authentication program image, but the example embodiment is not limited thereto.

[0074] In the second state 102, the fourth software image IMG4 can be loaded into system memory 14 as a program image. For example, the authenticated third software image IMG3 can load the fourth software image IMG4 from system storage device 16 into system memory 14, and can attempt to authenticate the loaded fourth software image IMG4. Authentication of the fourth software image IMG4 can be attempted using, for example, a soft key, based on key information associated with the fourth software image IMG4. That is, the key information of the fourth software image IMG4 may include a value indicating a desired soft key. In some example embodiments, the processor 12 may identify one of the soft keys included in the first software image IMG1 and the second software image IMG2 as a desired soft key associated with the fourth software image IMG4 based on a key index included in the key information of the fourth software image IMG4, and may attempt to authenticate the fourth software image IMG4 using the desired soft key (e.g., the identified soft key). For example, processor 12 may access first software image IMG1 and second software image IMG2 in sequential order (or in reverse order) to obtain identifiers of the soft keys of first software image IMG1 and second software image IMG2, and determine the software key corresponding to the identifier that matches the same key index, but the example embodiment is not limited thereto.

[0075] In the third state 103, the fourth software image IMG4 can be authenticated. For example, the first software image IMG1 may include a soft key corresponding to the key index included in the key information of the fourth software image IMG4, and the digital signature included in the fourth software image IMG4 can be successfully verified using the corresponding soft key, but the example embodiment is not limited thereto.

[0076] Figure 11 This is a block diagram of an example of a mirror signature system 110 according to at least one example embodiment. Figure 11 As shown, the mirror signature system 110 can generate signatures that can be stored in memory. Figure 1 The software image IMG is stored in the system storage device 16, but the example embodiment is not limited thereto.

[0077] The image signature system 110 can be implemented as any computing system, but the example embodiments are not limited thereto. For example, each component of the image signature system 110 can be implemented as a dedicated hardware module designed through logic synthesis, a dedicated software module executed by at least one processor core and / or processing circuitry, a processing unit including at least one processor core and a dedicated software module, and / or any combination thereof. The image signature system 110 can receive image generation information GEN. For example, the image generation information GEN may include the type of the software image IMG (i.e., a program image or a key chain image) (e.g., image type information), and the key type (e.g., key type information) used to authenticate the associated and / or corresponding software image IMG. The image generation information GEN can be provided to components included in the image signature system 110, but the example embodiments are not limited thereto. Figure 11 As shown, the mirror signature system 110 may include processing circuitry 111, and processing circuitry 111 may include at least one dedicated hardware or software module (such as a key generator 112, a buffer 114, a signature generator 116, and / or a signature mirror generator 118, etc.), but the example embodiments are not limited thereto. For example, processing circuitry 111 may more specifically include, but is not limited to, a central processing unit (CPU), an arithmetic logic unit (ALU), a digital signal processor (DSP), a graphics processing unit (GPU), a communication processor (CP), a microcomputer, a field-programmable gate array (FPGA), a system-on-a-chip (SoC), a programmable logic unit, a microprocessor, an application-specific integrated circuit (ASIC), etc., and according to some example embodiments, processing circuitry 111 may also include one or more of the following: an interface, a bus, a memory, and / or a controller.

[0078] According to at least one example embodiment, key generator 112 can generate a key pair including a private key and a public key. For example, key generator 112 may include a random number generator and can generate key pairs based on random numbers (e.g., a seed number). Figure 11 As shown, the key generator 112 can generate a soft key KEY corresponding to the public key in the key pair. S Provided to buffer 114, and can be used to obtain the soft private key PRV corresponding to the private key in the key pair. S Provided to signature generator 116. In some example embodiments, such as Figure 11 As shown by the dashed arrow in the image, the key generator 112 can generate not only soft keys KEY S Furthermore, it can generate a hard key KEY corresponding to the public key in the key pair. H And can be associated with the hard key KEY H The corresponding hard private key PRV HThe soft key KEY H is provided to the signature generator 116. In some example embodiments, the key generator 112 can be omitted, and the image signature system 110 can receive the key pair from an external (e.g., an external source, a user, etc.).

[0079] The buffer 114 can receive the soft key KEY H from the key generator 112. The buffer 114 can include a memory, but is not limited thereto. The buffer 114 can collect the soft key KEY S , can generate the key chain KCH, and can provide the key chain KCH to the signed image generator 118. In some example embodiments, the buffer 114 can generate the header HEA based on the image generation information GEN, and can provide the header HEA with the key chain KCH to the signed image generator 118. In some example embodiments, the buffer 114 can be omitted together with the key generator 112, and the image signature system 110 can receive the key chain KCH from an external (e.g., an external source, etc.).

[0080] The signature generator 116 can receive the soft private key PRV S from the key generator 112, and can generate a digital signature SIG derived from the soft private key PRV S according to at least one example embodiment, but is not limited thereto. Accordingly, the digital signature SIG can be verified by the soft key KEY S included in the key pair and the soft private key PRV S from which the digital signature SIG is derived. The digital signature SIG can be generated based on an arbitrary signature algorithm, but is not limited thereto. For example, the digital signature SIG can be generated from the soft private key PRV S based on an Elliptic Curve Digital Signature Algorithm (ECDSA), etc. Further, as shown in Figure 11 , the signature generator 116 can receive a hard private key PRV H from an external source, and can generate not only the digital signature SIG verified by the soft key KEY S but also the digital signature SIG verified by the hard key KEY H , etc.

[0081] According to at least one example embodiment, the signed image generator 118 can receive the binary image BIN, the key chain KCH, and the digital signature SIG, etc., and can generate the software image IMG. For example, the signed image generator 118 can generate the key information based on the image generation information GEN, and can generate the software image IMG including the binary image BIN, the digital signature SIG, and the key information as a program image, etc. Also, the signed image generator 118 can generate the key information based on the image generation information GEN, and can generate the software image IMG including the key chain KCH, the digital signature SIG, and the key information as a key chain image, etc. The signed image generator 118 can generate the program image and the key chain image in the same manner except that the data included in the software image IMG is the binary image BIN or the key chain KCH, but example embodiments are not limited thereto.

[0082] Figure 12 is a flowchart of an example of a method of authenticating software according to at least one example embodiment. Specifically, Figure 12 the flowchart illustrates an example of a method of generating a signed software image according to at least one example embodiment. In some example embodiments, Figure 12 the method of Figure 11 may be performed by the image signing system 110 of Figure 12 As shown in the method of generating a signed software image can include operations S10 and S30. In some example embodiments, operations S10 and S30 can be performed in a different order from that shown in Figure 12 and / or operations S10 and S30 can be performed in parallel. Hereinafter, the method of Figure 11 will be described with reference to Figure 12 .

[0083] In some example embodiments, Figure 12 the method of may be performed by at least one processor (e.g., processing circuitry, etc.) configured to execute program codes including computer-readable instructions corresponding to each operation. The instructions can be stored in a memory. The term "processor" can mean a hardware-implemented data processing apparatus including a circuit of a physical structure for performing a desired and / or predetermined operation, including an operation represented by instructions and codes included in a program. In some example embodiments, non-limiting examples of the hardware-implemented data processing apparatus can include a microprocessor (MP), a central processing unit (CPU), a processor core, a multi-core processor, a multi-processor, an application-specific integrated circuit (ASIC), and / or a field-programmable gate array (FPGA), etc.

[0084] In operation S10, an operation of generating a signed program image can be performed. For example, the image signing system 110 can generate a signed program image including a binary image BIN, etc. Examples of operation S10 will be described below with reference to FIG. 1, but example embodiments are not limited thereto. Figure 13 Examples of operation S10 will be described below with reference to FIG. 1, but example embodiments are not limited thereto.

[0085] In operation S30, an operation of generating a signed keychain image can be performed. For example, the image signing system 110 can generate a signed program image including a keychain KCH including at least one soft key, etc. Examples of operation S30 will be described below with reference to FIG. 2, but example embodiments are not limited thereto. Figure 14 Examples of operation S30 will be described below with reference to FIG. 2, but example embodiments are not limited thereto.

[0086] Figure 13 is a flowchart of an example of a method of authenticating software according to at least one example embodiment. Specifically, Figure 13 the flowchart of FIG. 1 illustrates Figure 12 Examples of operation S10 of FIG. 1 will be described below, but example embodiments are not limited thereto. As described above with reference to FIG. 1, in operation S10, an operation of generating a signed program image can be performed, but example embodiments are not limited thereto. Figure 12 Examples of operation S10 of FIG. 1 will be described below, but example embodiments are not limited thereto. As described above with reference to FIG. 1, in operation S10, an operation of generating a signed program image can be performed, but example embodiments are not limited thereto. Figure 13 Examples of operation S10 of FIG. 1 will be described below, but example embodiments are not limited thereto. As described above with reference to FIG. 1, in operation S10, an operation of generating a signed program image can be performed, but example embodiments are not limited thereto. Figure 13 As shown in FIG. 1, operation S10' can include a plurality of operations S11 to S17, but example embodiments are not limited thereto. Hereinafter, operation S10' will be described with reference to operations S11 to S17. Figure 11 Examples of operation S10 of FIG. 1 will be described below, but example embodiments are not limited thereto. As described above with reference to FIG. 1, in operation S10, an operation of generating a signed program image can be performed, but example embodiments are not limited thereto. Figure 13 Examples of operation S10 of FIG. 1 will be described below, but example embodiments are not limited thereto. As described above with reference to FIG. 1, in operation S10, an operation of generating a signed program image can be performed, but example embodiments are not limited thereto.

[0087] In operation S11, an operation of obtaining a binary image BIN can be performed. For example, the image signing system 110 can receive a binary image BIN including a series of instructions from an external source, etc.

[0088] In operation S12, an operation of determining a key type associated with the obtained binary image BIN can be performed. For example, the image signing system 110 can determine a key type associated with the obtained binary image BIN based on the image generation information GEN. As described above with reference to FIG. 1, the image signing system 110 can determine a key type associated with the obtained binary image BIN based on the image generation information GEN. Figure 13 As shown in FIG. 1, when the key type associated with the obtained binary image BIN is a hard key, operation S13 can be subsequently performed. Otherwise, if the key type associated with the obtained binary image BIN is a soft key, operation S15 can be sequentially performed.

[0089] When the key type is a hard key, an operation of generating a signature verified by the hard key can be performed in operation S13. For example, the signature generator 116 can receive a corresponding hard private key PRV H corresponding to the hard key KEY H based on the image generation information GEN, and can generate a signature verified by the hard key KEY HThe verified digital signature SIG is used, but the example embodiment is not limited to this. Next, in operation S14, an operation can be performed to generate key information including a value indicating the hard key. For example, the signed image generator 118 can generate key information including a value indicating and / or identifying the desired hard key used to verify the software image based on image generation information GEN. In some example embodiments, when at least two hard keys are used to authenticate the software image, the key information may include not only a value indicating the type of key that will be used to verify the software image (e.g., a value indicating the hard key used, etc.), but also a key index for identifying the desired hard key associated with the software image.

[0090] When the key type information indicates that the expected key associated with the software image is a soft key, an operation to generate a signature verified by the soft key can be performed in operation S15. For example, the signature generator 116 can receive the soft key KEY from outside the key generator 112 or the image signing system 110 (e.g., an external source) based on the image generation information GEN. S The corresponding soft private key PRV S And it can generate a soft key KEY S The verified digital signature SIG. Next, in operation S16, an operation can be performed to generate key information including a value indicating the type of the soft key and an index of the desired soft key associated with the software image. For example, based on the image generation information GEN, the signing image generator 118 can generate key information including a value indicating the type of the soft key and an index (e.g., a key index, etc.) that can identify the desired soft key associated with the software image in a key chain image including the soft key.

[0091] In operation S17, an operation to generate a program image for signature can be performed. For example, the signature image generator 118 can generate a program image for signature including binary image BIN, key information, and digital signature SIG, but is not limited to this.

[0092] Figure 14 This is a flowchart of a method for authentication software according to at least one example embodiment. Specifically, Figure 14 The flowchart shows Figure 12 This is an example of operation S30, but the example embodiment is not limited thereto. As referred to above... Figure 12 As mentioned above, it is possible to Figure 14 Operation S30' performs the operation of generating a keychain image with a signature, but the example embodiment is not limited to this. For example... Figure 14 As shown, operation S30' may include multiple operations S31 to S37, but the example embodiment is not limited thereto. In the following, reference will be made to... Figure 11 describe Figure 14 The flowchart, and will omit the previous referenceFigure 13 The description of the described aspects is the same as the description of the same aspects.

[0093] In operation S31, an operation of obtaining a key chain can be performed. For example, the image signing system 110 can generate a key chain KCH including at least one soft key as shown in Figure 11 operation S12 to S16 of FIG. 1, but example embodiments are not limited thereto.

[0094] In some example embodiments, Figure 14 operations S32 to S36 of FIG. 2 can be the same as Figure 13 operations S12 to S16 of FIG. 1, but example embodiments are not limited thereto. Thus, the program image and the key chain image can have the same structure except for data (i.e., the binary image BIN or the key chain KCH) included therein.

[0095] In operation S37, an operation of generating a signed key chain image can be performed. For example, the signed image generator 118 can generate a signed key chain image including the key chain KCH, the key information, and the digital signature SIG, etc.

[0096] The various operations of methods described above with reference to the Figures can be performed by any suitable means capable of performing the operations, such as various hardware or software component(s), circuitry, one or more processing circuit(s), or one or more processing circuit(s) executing software, etc. Software can include one or more computer readable instructions stored on a computer readable medium, which when executed by a processing circuit, cause the processing circuit to perform the described operations. A computer readable medium can include any medium capable of storing instructions for execution by a processing circuit. Examples of computer readable medium include a computer readable storage medium, a computer readable memory medium, and a computer readable recording medium.

[0097] The methods or algorithms and functions described in connection with the examples embodiments disclosed herein can be embodied directly in hardware, in software executed by hardware, or in a combination of the two. Software can include one or more computer readable instructions stored on a computer readable medium, which when executed by a processing circuit, cause the processing circuit to perform the described methods or algorithms and functions. The computer readable medium can include any medium capable of storing instructions for execution by a processing circuit. Examples of computer readable medium include a computer readable storage medium, a computer readable memory medium, and a computer readable recording medium.

[0098] While the inventive concept has been particularly shown and described with reference to exemplary embodiments thereof, it will be understood that various changes in form and details can be made therein without departing from the spirit and scope of the claims.

Claims

1. A system for authentication of software, comprising: a system memory configured to store at least one software image, the at least one software image comprising at least a program image and a keychain image associated with the at least one software image, the keychain image comprising at least one soft key; and a processing circuitry configured to: determine, based on key information included in the at least one software image, a key type for authenticating the at least one software image, obtain, based on the determination, either a hard key or a desired soft key associated with the at least one software image from the keychain image, and authenticate the at least one software image based on the obtained hard key or the obtained soft key.

2. The system of claim 1, wherein, The processing circuitry comprises at least one hard key.

3. The system of claim 2, wherein, The processing circuitry comprises a secure memory configured to store the at least one hard key.

4. The system of claim 2, wherein, The processing circuitry is configured to obtain the at least one hard key from a second software image loaded in the system memory.

5. The system of claim 2, wherein, The processing circuitry is configured to: identify, based on the key information included in the at least one software image, a desired hard key associated with the at least one software image from among the at least one hard key; and authenticate the at least one software image based on the desired hard key. The processing circuitry is configured to authenticate the at least one software image by verifying a digital signature included in the at least one software image based on the obtained soft key.

6. The system of claim 1, wherein, The processing circuitry is configured to identify, based on a key index included in the key information, the desired soft key associated with the at least one software image in the keychain image.

7. The system of claim 1, wherein, 8. The system according to claim 1, wherein the system memory is configured to store a plurality of keychain images, the plurality of keychain images comprising a plurality of soft keys; and the processing circuitry is configured to obtain the desired soft key from among the plurality of soft keys based on the key information.

9. The system according to any one of claims 1 to 8, further comprising: a system storage configured to store a plurality of software images, the plurality of software images comprising the at least one software image, and wherein the processing circuitry is configured to load the at least one software image from the system storage into the system memory. The method is performed by a processing circuitry, the method comprising:

10. A method of authenticating a software image loaded in a system memory, wherein, authenticating a first software image, the first software image comprising first key information and at least one soft key; and authenticating a second software image, the second software image comprising second key information, the step of authenticating the second software image comprising: obtaining the second key information from the second software image, determining, based on the second key information, a key type for authenticating the second software image, obtaining, based on the determination, either a hard key or a first soft key from the authenticated first software image, and verifying a digital signature of the second software image based on the obtained hard key or the first soft key. The step of authenticating the first software image comprises:

11. The method of claim 10, wherein, obtaining the first key information from the first software image; obtaining, based on the first key information, a hard key included in the processing circuitry; and verifying a digital signature of the first software image based on the hard key.

12. The method according to claim 10, further comprising: ​ authenticating a third software image, the third software image including third key information, the third key information being different from the second key information; and wherein the step of authenticating the third software image includes, obtaining the third key information from the third software image, obtaining a second soft key from the first software image based on the third key information, the second soft key being different from the first soft key; and and verifying a digital signature of the third software image based on the second soft key.

13. The method of claim 10, further comprising: authenticating a fourth software image, the fourth software image including fourth key information; and wherein the step of authenticating the fourth software image includes, obtaining the fourth key information from the fourth software image, obtaining a third soft key from the authenticated second software image based on the fourth key information, and verifying a digital signature of the fourth software image based on the third soft key.

14. The method of claim 10, wherein, The second key information includes a key index for identifying the first soft key from the at least one soft key included in the first software image.

15. A method of generating signed software images for authentication of software in a system, the system including processing circuitry, the method comprising: generating a program image as a signed software image, the program image to be executed by the system; and generating a key chain image as a signed software image, the key chain image including at least one soft key, the step of generating the program image including: obtaining a first binary image, the first binary image including computer readable instructions, determining a key type associated with the first binary image, based on the determination, generating a first signature, the first signature being verified based on a hard key or a first soft key, and generating a first signed program image, the first signed program image including the first binary image and the first signature.

16. The method of claim 15, wherein, The step of generating the first signed program image includes generating key information, the key information including a first key type value indicating use of a soft key for authentication and a first key index identifying the first soft key from a plurality of soft keys.

17. The method of claim 15, wherein, The step of generating the key chain image includes: obtaining a hard key included in the system; obtaining a first key chain, the first key chain including the first soft key; generating a second signature, the second signature being verified based on the hard key; and generating a first signed key chain image, the first signed key chain image including the first key chain and the second signature.

18. The method of claim 15, wherein, The step of generating the program image further includes: obtaining a hard key included in the system; obtaining a second binary image, the second binary image including computer readable instructions; generating a third signature verified based on the hard key; and generating a second signed program image, the second signed program image including the second binary image and the third signature.

19. The method of claim 15, wherein, The step of generating the key chain image includes: obtaining a second soft key; obtaining a second key chain, the second key chain including at least one soft key; generating a fourth signature, the fourth signature being verified based on the second soft key; and generating a second signed key chain image, the second signed key chain image including the second key chain and the fourth signature.

Images