Method of controlling access rights to security-required resources in a shared bus by a hardware security module, a device using it, and an SoC semiconductor chip

Abstract

The present invention relates to a method for controlling access rights to security-required resources on a shared bus by a hardware security module during the design and operation of an SoC semiconductor chip, and to a device and semiconductor chip capable of controlling access rights to security-required resources. When implementing an independent bus for encryption settings, a separate bus is separated so that a certain portion of the encryption key can be set and operated even in the part that processes IDE in PCIe, and a separate bus is also separated in the hardware security module so that it can be directly connected to a PCI IDE encryption key related module, thereby enhancing security.

Description

Technology Field

[0001] The present invention relates to a method for controlling access rights to security-required resources on a shared bus by a hardware security module during the design and operation of an SoC semiconductor chip, and to a device and a semiconductor chip capable of controlling access rights to security-required resources. Background Technology

[0002] As the demand for AI / HPC increases, data centers and other facilities are implementing these requirements through NPU accelerators.

[0003] In such systems, technical standards for device authentication of data processing units, access restrictions during data communication, and encrypted communication are established, and when implementing a system-on-chip, these requirements must be satisfied.

[0004] For device authentication, the Open Computing Project established a standard for a hardware security module design called Caliptra, and the PCIe specification proposed device authentication using the SPDM protocol and PCIe encryption standard transmission using encryption via IDE (Integrity and Device Encryption).

[0005] In these encryption standard transmission methods and devices, the authentication process of the PCI device is carried out according to a standard called SPDM (Secure Protocol and Data Model) before data transmission encryption. Once authentication is complete, a key exchange process is performed using ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).

[0006] And when establishing encrypted communication using the exchanged key, there is a process of setting the encryption key to be used for encryption during PCIe communication using the IDE_KM protocol defined in the PCI specification, and the device that receives the command adopts a method of setting the encryption key through a bus that can be independently accessed from the system-on-chip.

[0007] FIGS. 1 and FIGS. 2 illustrate examples of implementing a hardware security module configured to allow independent access to an existing system-on-chip. FIGS. 1 is a configuration where both the HSM and the application can access the PCI IDE Key module, and FIGS. 2 is a structure where only the HSM can access it.

[0008] In the implementation of the conventional system-on-chip shown in Figures 1 and 2, the part for setting the encryption key is implemented as an independent bus, which allows access only to the hardware security module, and causes a problem where access itself is not possible from other main processors, such as ARM CPUs.

[0009] In places where the entire device runs only authenticated software depending on the application of the system-on-chip, even in places where implementing security software in the main processor is sufficient, the access restriction of the encryption key management module poses a problem that significantly limits the ease of implementation.

[0010] Figure 1 is configured so that both the application processor and the hardware security module (HSM) are configurable. In this case, even if the HSM is responsible for the IDE Key setting function, there is a problem that the Key Register can be updated if there is a security vulnerability in the application processor.

[0011] In the case of Figure 2, a PCI IDE (Integrity and Data Encryption) Key setting port is connected to the HSM. However, in this case, there is a problem where implementation becomes complex if the device is configured with a single security level without other user services. There is also a problem where unnecessary means of communication with the HSM must be implemented for IDE Key setting when implementing SW in the AP. Prior art literature

[0012] Republic of Korea Published Patent No. 10-2020-0099065 (Published August 21, 2020) The problem to be solved

[0013] Therefore, the objective of the present invention is to provide an apparatus and method that enable access to a key setting module in a PCIe IDE via an independent bus and a shared bus, and control access from the shared bus as needed to enhance security, thereby providing ease of implementation according to the purpose of use. means of solving the problem

[0014] A method for controlling access rights to security request resources in a shared bus by a hardware security module of the present invention for achieving the above-mentioned purpose comprises: a) a step of, upon system booting, causing the hardware security module to load a setting value from a setting value storage module connected to the hardware security module that cannot be tampered with by external software, and, according to the loaded setting value, controlling a key management bus permission control module to block or allow bus access for encryption key setting in the shared bus; b) a step of performing an access request for an encryption key setting portion using a shared bus distinguished from an independent bus for encryption key setting in an application processor; c) a step of, in response to the access request for the encryption key setting portion, determining whether the key management bus access permission control module corresponds to an access request set by the hardware security module; and d) a step of allowing or blocking the access path of the shared bus through the key management bus interconnect in a bus permission control unit according to the determination result of the key management bus access permission control module. and e) a step of performing encryption key settings in the Key register in response to an access request to the encryption key setting portion when an access path to the shared bus is allowed through the Key management bus interconnect;

[0015] In one embodiment, the access rights to security request resources of a first security level are set only within the hardware security module, and the access rights to security request resources of a second security level, which is a security level lower than the first level, are further set to be processable in the application processor.

[0016] According to another embodiment of the present invention, a device capable of controlling access rights to security request resources in a shared bus by a hardware security module comprises: an application processor; a hardware security module connected to an independent bus for securely generating, storing, and managing encryption keys and setting encryption keys; a bus access rights control module for Key Management that is granted access rights for setting encryption keys by the hardware security module, receives an access request for an encryption key setting portion using a shared bus distinct from the independent bus for setting encryption keys by the application processor, responds to the access request for the encryption key setting portion to determine whether it corresponds to an allowed access request, and transmits a signal to block or allow bus access for setting encryption keys in the shared bus; and a bus permission control unit for allowing or blocking an access path based on whether the path is allowed by the bus access rights control module for Key Management for Access to the encryption key setting portion transmitted by the application processor.

[0017] In one embodiment, the device further includes a Key management bus interconnect connected between the bus permission control unit and the Key register to block or allow access of the application processor according to a set permission.

[0018] In one embodiment, the Key Management Bus Interconnect is implemented as AMBA (Advanced Microcontroller Bus Architecture) to restrict access separately for secure and non-secure access, or to restrict access to only secure access.

[0019] In one embodiment, the Key Management Bus Interconnect is connected to the hardware security module through the TrustZone Protection Controller (TZPC).

[0020] In one embodiment, the PCI IDE that performs PCI packet encryption and decryption in the device includes a first APB port for an IDE Key register only for the confidentiality of the Key management portion and a second APB port for a general IDE module register for IDE-related monitoring and settings unrelated to confidentiality.

[0021] In one embodiment, the first APB port is connected so that it can receive key settings only through a hardware security module.

[0022] In one embodiment, the shared bus of the device is an AXI bus, and the protocol signals indicating the secure and non-secure access are AWPROT[1] and ARPROT[1], where AWPROT[1] and ARPROT[1] are '1', it means non-secure access rights, and where AWPROT[1] and ARPROT[1] are '0', it means secure access rights.

[0023] In one embodiment, the key management bus access authority control module sets whether access to the shared bus is possible, and when security confidentiality is required, the key management bus access authority control module allows only configuration through the path between the independent bus and the key management bus interconnect by the hardware security module, and when security access to the application processor is permitted, the control of the bus permission control unit is changed through the key management bus access authority control module to permit control through the shared bus.

[0024] In one embodiment, access rights to security request resources at a first security level are set only within the hardware security module, and access rights to security request resources at a second security level, which is a lower security level than the first level, can be processed by the application processor.

[0025] According to another embodiment of the present invention, an SoC semiconductor chip capable of controlling access rights to security request resources on a shared bus by a hardware security module comprises: an application processor module; a shared bus connected to the application processor module and connected to one or more hardware modules; a hardware security module connected to an independent bus for securely generating, storing, and managing encryption keys and for setting encryption keys; a key management bus access rights control module for receiving access rights for setting encryption keys from the hardware security module, receiving an access request for an encryption key setting portion using the shared bus which is distinct from the independent bus for setting encryption keys from the application processor module, and responding to the access request for the encryption key setting portion to determine whether it corresponds to an allowed access request, and transmitting a signal to block or allow bus access for setting encryption keys on the shared bus; an independent bus connected to the hardware security module and the key management bus access rights control module and independent from the shared bus; and a bus permission control unit for allowing or blocking an access path based on whether the path is allowed from the key management bus access rights control module for an access request to the encryption key setting portion transmitted from the application processor module. Effects of the invention

[0026] According to the present invention, by implementing a certain portion of security-related processing in the application processor, the processing burden of the hardware security module can be reduced, and accordingly, the implementation of the hardware security module can be made easier. Furthermore, depending on the system operation scenario, the application process can directly access the PCI IDE Key configuration module (located within the PCIe block), thereby facilitating software development, that is, making it easier to develop functions such as SPDM on a Rich OS. In environments requiring a high level of security, various system configurations can be enabled to strengthen security by blocking the application from accessing the PCI IDE Key module through the shared bus and processing only within the HSM, thereby creating various SoC operation scenarios.

[0027] In addition, according to the present invention, the encryption key setting portion is configured to be accessible from a shared bus in addition to an independent bus for encryption key setting, and through such access, the function of controlling access blocking in a hardware security module is controlled, thereby enabling ease of implementation and convenience during the development verification phase according to system requirements. Brief explanation of the drawing

[0028] FIGS. 1 and FIGS. 2 illustrate examples of implementing a hardware security module configured to allow independent access to an existing system-on-chip. FIGS. 1 is a configuration where both the HSM and the application can access the PCI IDE Key module, and FIGS. 2 is a structure where only the HSM can access it. FIG. 3 schematically illustrates a device capable of controlling access rights to security-required resources in a shared bus according to one embodiment of the present invention. FIG. 4 shows the internal circuit configuration of a bus permission control unit according to one embodiment of the present invention. Figure 5 is a flowchart schematically illustrating a method for controlling access rights to security request resources on a shared bus by a hardware security module. Specific details for implementing the invention

[0029] The following detailed description of the invention refers to the accompanying drawings, which illustrate specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It should be understood that various embodiments of the invention are different but need not be mutually exclusive. For example, specific shapes, structures, and characteristics described herein with respect to one embodiment may be implemented in other embodiments without departing from the spirit and scope of the invention. It should also be understood that the location or arrangement of individual components within each disclosed embodiment may be changed without departing from the spirit and scope of the invention. Accordingly, the following detailed description is not intended to be limiting, and the scope of the invention is limited only by the appended claims, including all equivalents to those claimed therein, provided appropriately described. Similar reference numerals in the drawings refer to the same or similar functions across various aspects.

[0030] Terms such as "first" or "second" may be used to describe various components, but these terms should be interpreted solely for the purpose of distinguishing one component from another. For example, the first component may be named the second component, and similarly, the second component may be named the first component.

[0031] When it is stated that a component is "connected" to another component, it should be understood that it may be directly connected to or coupled with that other component, or that there may be other components in between.

[0032] The singular expression includes the plural expression unless the context clearly indicates otherwise. In this specification, terms such as "comprising" or "having" are intended to specify the existence of the described features, numbers, steps, actions, components, parts, or combinations thereof, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0033] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as generally understood by those skilled in the art. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and should not be interpreted in an ideal or overly formal sense unless explicitly defined in this specification.

[0034] Hereinafter, embodiments will be described in detail with reference to the attached drawings. In the description with reference to the attached drawings, identical components are given the same reference numeral regardless of the drawing number, and redundant descriptions thereof will be omitted.

[0035] FIG. 3 schematically illustrates a device capable of controlling access rights to security-required resources in a shared bus according to one embodiment of the present invention.

[0036] Referring to FIG. 3, the device (100) according to the present invention includes a hardware security module (101), an application processor (102), a shared bus (103), an independent bus (104), a bus access permission control module for key management (105), a bus interconnect for IDE key management (109), a bus permission control unit (110), and a PCI IDE (114). Additionally, the device (100) according to another embodiment of the present invention may optionally further include a TZPC (116).

[0037] Other components of the device (100) according to the present invention are components of a general SoC device, and a specific description is omitted.

[0038] The hardware security module (101) is connected to the bus access control module (105) for key management, the TZPC (TrustZone Protection Controller, 116), and the IDE key management bus interconnect (109) via an independent bus (104).

[0039] And the application processor (102) is connected to peripheral device hardware, namely the PCI Module (Peripheral Component Interconnect Physical Layer), via a shared bus (103). The PCI Module includes a PCI IDE (Peripheral Component Interconnect Integrated Drive Electronics, 114) and a PCI CTRL (115), and may be connected to the shared bus (103) via APB and AXI, respectively. At this time, the PCI IDE (114) may be connected via a general IDE module register (113).

[0040] Meanwhile, referring to FIG. 3, the bus permission controller (110) is controlled by a bus access authority control module (150) for key management and is connected to a shared bus (103) and an IDE key management bus interconnect (109).

[0041] The IDE Key management bus interconnect (109) is connected to the IDE KEY register (112) of the PCI IDE (114).

[0042] Generally, a hardware security module is composed of an independent part of the system, consisting of a CPU core such as RISC-V, a hardware encryption module, and a public key generation module, and includes SRAM within several hundred KB to operate security module services. In this case, there are many constraints in terms of ease of FW implementation and portability with other hardware security modules when implementing the Device Security Manager (DSM) required by PCI for device authentication and encrypted communication setup.

[0043] For example, each company that manufactures hardware security module IP differs in security hardware access libraries, operating systems, SPDM protocol transport techniques over PCI (Data Object Exchange, MTCP (SMBUS)), resource constraints, etc. As a result, it was not easy to fully implement DSM in a hardware security module.

[0044] In contrast, the device (100) according to the present invention illustrated in FIG. 3 is designed to enhance security by implementing an independent bus for encryption settings, and by configuring the part that processes IDE in PCIe to connect a part that is different from the part that sets and operates encryption keys to an independent bus for this purpose, and by separating a separate bus in the hardware security module so that it can be directly connected to the PCI IDE encryption key management module. Additionally, the hardware security module (101) is also configured to be directly connected to the PCI IDE encryption key related module through an independent bus (104). Through this, the device (100) according to the present invention can enhance security.

[0045] In the present invention, the encryption key setting portion is configured to be accessible from the shared bus (103) in addition to the independent bus (104) for encryption key setting.

[0046] Specifically, the hardware security module (101) of the device (100) capable of controlling access rights to security-required resources in a shared bus by the hardware security module according to the present invention is connected to an independent bus (104) for securely generating, storing, and managing encryption keys and setting encryption keys.

[0047] And the bus access authority control module (105) for key management is granted access authority for encryption key setting from the hardware security module (101), receives an access request for the encryption key setting section using a shared bus (103) that is distinct from the independent bus (104) for encryption key setting from the application processor (102), and in response to the access request for the encryption key setting section, determines whether it corresponds to an allowed access request and transmits a signal to allow or block the access request path for the encryption key setting section using the shared bus (104). That is, the bus access authority control module (105) for key management is granted access authority for encryption key setting from the hardware security module (101), receives an access request for the encryption key setting section using a shared bus that is distinct from the independent bus for encryption key setting from the application processor (102), and in response to the access request for the encryption key setting section, determines whether it corresponds to an allowed access request and transmits a signal to block or allow bus access for encryption key setting on the shared bus.

[0048] That is, the independent bus (104), which is an independent bus, is responsible for processing the encryption key setting portion from the hardware security module (101), and the shared bus (103) is implemented to process the encryption key setting portion handled by the application processor (102) in addition to the general IDE processing portion from the application processor (102).

[0049] In this case, access rights to security request resources at the first security level are set only within the hardware security module (101), and access rights to security request resources at the second security level, which is a lower security level than the first level, can be set to be processed by the application processor (102).

[0050] Meanwhile, the bus permission control unit (110) has the function of allowing or blocking an access path based on whether the path is allowed by the bus access permission control module (105) for key management, in response to an access request for an encryption key setting part transmitted from the application processor (102).

[0051] Additionally, the Key management bus interconnect (109) is connected between the bus permission control unit (110) and the Key register (112), and performs the function of blocking or allowing access by the application processor (102), that is, access to the encryption key setting part, according to the set authority.

[0052] In the embodiment illustrated in FIG. 3, the shared bus (103) is a shared bus that processes IDE in PCIe, the Key register is an IDE Key register, and the Key management bus interconnect is an IDE Key management bus interconnect.

[0053] Also, the IDE Key Management Bus Interconnect (109) can be implemented with AMBA (Advanced Microcontroller Bus Architecture) to restrict access by security and non-security, or to restrict access to only security access.

[0054] In this case, the IDE Key management bus interconnect (109) can be connected to the hardware security module (101) through the TZPC (TrustZone Protection Controller).

[0055] That is, in the present invention, a Key Management Bus Interconnect (e.g., ARM AXI Interconnect, 109) is provided, and the Key Management Bus Interconnect (109) is connected to the Key Register (112), and also blocks or permits access by the application processor (102) according to the configured authority. When the Key Management Bus Interconnect (109) is implemented with AMBA, it can perform access restrictions based on security / non-security, or it can be fixed to allow only security access. This configuration can be achieved by utilizing ARM's TZPC.

[0056] To describe an optional embodiment of FIG. 3, if nonsecure access is also enabled in the access restriction settings of the TZPC (116), the application processor (102) may be able to access in all modes.

[0057] These security settings are made according to the output signal of the bus access control module (105) for key management, and since these settings can be configured only with the independent bus (104) connected only to the application processor (102), the security level can be maintained.

[0058] Meanwhile, the PCI IDE that performs PCI packet encryption and decryption in the above device (100) includes a first APB port for the IDE Key register (112) only for the confidentiality of the Key management part and a second APB port for the general IDE module register (113) for IDE-related monitoring and settings unrelated to confidentiality, and the first APB port is connected so that key settings can be received only by the hardware security module.

[0059] Again, referring to FIG. 3, the system configuration method setting of the device (100) according to the present invention is typically implemented by loading and determining the setting value of the OTP (117) connected to the hardware security module (101).

[0060] A method is performed to control access rights by reading the OTP value by the hardware security module (101) at the time of system booting, setting access rights control using the APB Port of the bus access rights control module (105) for key management according to the set value, and proceeding with the booting of the application processor (102).

[0061] This allows only authorized CPUs or other masters to access the APB Port of the APB (111) between the Key Management Bus Interconnector (109) and the PCI IDE (114).

[0062] In other words, the present invention means enabling access to the shared bus in a bus access control module for key management, and in the application example of TZPC, secure / non-secure access of an application process can be distinguished and permitted through the separate access of secure / non-secure access of TZPC. In this case, secure / non-secure corresponds to the content regarding Trustzone technology in ARM.

[0063] When security confidentiality is required, the hardware security module (101) in the Key management bus access authority control module (105) allows only the path of reference numeral 108 in FIG. 3 to be configured, and the hardware security module (101) blocks access to reference numeral 112 through the shared bus. If configured to be permitted, only the hardware security module (101) can access it. Furthermore, to allow secure access to the application processor (102), the control of the bus permission control unit (110) is changed through the Key management bus access authority control module (105) to allow control through the shared bus (103), that is, access to the IDE Key Reg APB Port (112) through the application process (102). In an embodiment of the present invention, if access through the shared bus (103) is permitted using the Key management bus access authority control module (105), access is simultaneously permitted from both the HSM and the application process.

[0064] In this embodiment, the PCI IDE (114) does not have access permission setting control, and the concept is that access to the Key Register (IDE Key Register APB Port) (112) can be configured to allow secure / non-secure access through the TZPC (116), and access to the Key Register (112) from the application processor (102) to the shared bus (103) is controlled by forcing the signals of secure / non-secure signals (AXPROT[1], AWPROT[1]) through the bus permission control unit (110). The signal coming from the path of reference numeral 108 is always made accessible by setting it to secure access (AXPROT[1] = 0, AWPROT[1] = 0), and access is blocked by overriding the signals of the bus permission control unit (110) through the control of the bus access permission control module (105) for key management.

[0065] FIG. 4 shows the internal circuit configuration of a bus permission control unit according to one embodiment of the present invention.

[0066] Referring to FIG. 4, an exemplary bus permission control unit (110) performs an OR gate operation on a signal transmitted from a bus access authority control module for key management and a signal transmitted from the application processor and outputs the result, thereby allowing or blocking a path based on the judgment of the bus access authority control module for key management.

[0067] In the embodiment of FIG. 4, when the shared bus of the device is an AXI bus, the protocol signals indicating secure and non-secure access are AWPROT[1] and ARPROT[1]. In this case, if AWPROT[1] and ARPROT[1] are '1', it means non-secure access rights, and if AWPROT[1] and ARPROT[1] are '0', it means secure access rights.

[0068] That is, if the signal transmitted from the bus access authority control module (105) for key management is '1', the bus permission control unit (110) will output only the '1' signal, and if the signal transmitted from the bus access authority control module (105) for key management is '0', the AWPROT[1] and ARPROT[1] signals will be output as they are. That is, the Disable Access Ctrl Signal controlled by the setting of (105) in Fig. 4 is ORed with ARPROT / AWPROT, so the access authority signal is forced to 1, and ultimately, it is transmitted as non-secure access. If non-secure access is blocked by the TZPC setting of (116), the bus of the shared bus is blocked, and if permission is granted in the TZPC setting, both the shared bus and HSM access can be processed.

[0069] Figure 5 is a flowchart schematically illustrating a method for controlling access rights to security request resources on a shared bus by a hardware security module.

[0070] Referring to FIG. 5, a method for controlling access rights to security request resources in a shared bus by a hardware security module according to the present invention includes an access right setting step (S11), an application processor encryption key setting access request step (S12), a determination step of whether the access request is allowed (S13), a step of allowing or blocking an access path (S14), and a step of proceeding with encryption key setting (S15).

[0071] In the access permission setting step (S11), when the system boots, the hardware security module is configured to load the setting value of the OTP connected to the hardware security module, and based on the loaded setting value, the access permission control setting of the bus access permission control module for key management is configured to grant access permission for encryption key setting.

[0072] In the application processor encryption key setting access request step (S12), the application processor performs an access request for the encryption key setting part using a shared bus that is distinct from the independent bus for encryption key setting.

[0073] In the step of determining whether it is an allowed access request (S13), in response to the access request for the encryption key setting part, the bus access authority control module for key management determines whether it corresponds to the access request set by the hardware security module.

[0074] In the step of allowing or blocking the access path (S14), the bus permission control unit allows or blocks the access path of the shared bus through the key management bus interconnect based on the result of judgment by the key management bus access authority control module.

[0075] And, in the encryption key setting process step (S15), when the access path of the shared bus through the Key management bus interconnect is allowed, the encryption key setting is performed in the Key register in response to the access request for the encryption key setting part.

[0076] In this way, the present invention enables enhanced security by separating a separate bus so that a certain portion of the encryption key can be set and operated even in the part that processes IDE in PCIe when implementing an independent bus for encryption settings, and by separating a separate bus in the hardware security module so that it can be directly connected to the PCI IDE encryption key related module.

[0077] In addition, according to the present invention, by implementing a certain portion of security-related processing in the application processor, the processing burden of the hardware security module can be reduced, and accordingly, the implementation of the hardware security module can be made easier. Furthermore, depending on the system operation scenario, the application process can directly access the PCI IDE Key configuration module (a module located within the PCIe block), thereby facilitating software development, that is, making it easier to develop functions such as SPDM on a Rich OS. In environments requiring a high level of security, various system configurations can be enabled to strengthen security by blocking the application from accessing the PCI IDE Key module through the shared bus and processing only within the HSM, thereby creating various SoC operation scenarios.

[0078] In addition, according to the present invention, the encryption key setting portion is configured to be accessible from a shared bus in addition to an independent bus for encryption key setting, and through such access, the function of controlling access blocking in a hardware security module is controlled, thereby enabling ease of implementation and convenience during the development verification phase according to system requirements.

[0079] Meanwhile, it will be readily understood by those skilled in the art that the present invention is not limited to the typical preferred embodiments described above, but can be implemented with various improvements, modifications, substitutions, or additions within the scope of the essence of the invention. If such implementation through improvements, modifications, substitutions, or additions falls within the scope of the appended claims below, the technical concept thereof should also be considered to belong to the present invention. Explanation of the symbols

[0080] 101: Hardware Security Module 102: Application Processor 103: Shared Bus 104: Independent bus 105: Bus access control module for key management 109: Key Management Bus Interconnect 110: Bus Permission Control Unit 116: TZPC

Claims

Claim 1 A method for controlling access rights to security request resources on a shared bus by a hardware security module comprises: a) a step of, upon system booting, causing the hardware security module to load a setting value from a setting value storage module connected to the hardware security module that is impossible to tamper with by external software, and, according to the loaded setting value, controlling a key management bus permission control module to block or allow bus access for encryption key setting on the shared bus; b) a step of performing an access request for an encryption key setting section using a shared bus that is distinct from an independent bus for encryption key setting in an application processor; c) a step of, in response to the access request for the encryption key setting section, determining whether the key management bus access permission control module corresponds to an access request set by the hardware security module; and d) a step of allowing or blocking the access path of the shared bus through the key management bus interconnect in a bus permission control unit according to the determination result of the key management bus access permission control module. and e) a step of performing encryption key setting in the Key register in response to an access request for the encryption key setting part when an access path to the shared bus is allowed through the Key management bus interconnect; characterized by including a security request resource access right control method. Claim 2 A method for controlling access rights to security request resources according to claim 1, further comprising the step of configuring access rights to security request resources at a security level of 1 to be configured only within the hardware security module, and configuring access rights to security request resources at a security level of 2, which is a lower security level than 1, to be processed by an application processor. Claim 3 A device capable of controlling access rights to security request resources on a shared bus by a hardware security module, comprising: an application processor; a hardware security module connected to an independent bus for securely generating, storing, and managing encryption keys and setting encryption keys; a key management bus access rights control module for receiving access rights for setting encryption keys from the hardware security module, receiving an access request for an encryption key setting section using a shared bus distinct from the independent bus for setting encryption keys from the application processor, responding to the access request for the encryption key setting section to determine whether it corresponds to an allowed access request, and transmitting a signal to block or allow bus access for setting encryption keys on the shared bus; and a bus permission control unit for allowing or blocking an access path based on whether the path is allowed by the key management bus access rights control module for the access request for the encryption key setting section transmitted from the application processor. Claim 4 A device according to claim 3, characterized in that the device further includes a Key management bus interconnect connected between the bus permission control unit and the Key register to block or allow access of the application processor according to a set authority. Claim 5 A device according to claim 4, characterized in that the Key Management Bus Interconnect is implemented in AMBA (Advanced Microcontroller Bus Architecture) to restrict access separately for secure and non-secure access, or to fix access so as to allow only secure access. Claim 6 A device according to claim 5, characterized in that the Key Management Bus Interconnect is connected to the hardware security module through a TZPC (TrustZone Protection Controller). Claim 7 A device according to claim 6, wherein the PCI IDE performing PCI packet encryption and decryption in the device comprises a first APB port for an IDE Key register only for the confidentiality of the Key management portion and a second APB port for a general IDE module register for IDE-related monitoring and settings unrelated to confidentiality. Claim 8 A device according to claim 7, characterized in that the first APB port is connected to receive key settings only through a hardware security module. Claim 9 A device according to claim 3, wherein the shared bus of the device is an AXI bus, and the protocol signals indicating secure and non-secure access are AWPROT[1] and ARPROT[1], wherein if AWPROT[1] and ARPROT[1] are '1', it signifies non-secure access rights, and if AWPROT[1] and ARPROT[1] are '0', it signifies secure access rights. Claim 10 A device according to claim 9, wherein the Key Management Bus Access Authority Control Module sets whether access to the shared bus is possible, and when security confidentiality is required, the Key Management Bus Access Authority Control Module allows only configuration through the path between the independent bus and the Key Management Bus Interconnect by the hardware security module, and when security access to the application processor is permitted, the Key Management Bus Access Authority Control Module changes the control of the bus permission control unit to permit control through the shared bus. Claim 11 A device according to claim 3, characterized in that access rights to security request resources of a first-grade security level are set only within the hardware security module, and access rights to security request resources of a second-grade security level, which is a lower security level than the first grade, can be processed by the application processor. Claim 12 An SoC semiconductor chip capable of controlling access rights to security request resources on a shared bus by a hardware security module, comprising: an application processor module; a shared bus connected to the application processor module and connected to one or more hardware modules; a hardware security module connected to an independent bus for securely generating, storing, and managing encryption keys and for setting encryption keys; a key management bus access rights control module for receiving access rights for setting encryption keys from the hardware security module, receiving an access request for an encryption key setting portion using the shared bus which is distinct from the independent bus for setting encryption keys from the application processor module, and responding to the access request for the encryption key setting portion to determine whether it corresponds to an allowed access request, and transmitting a signal to block or allow bus access for setting encryption keys on the shared bus; an independent bus connected to the hardware security module and the key management bus access rights control module and independent from the shared bus; and a bus permission control unit for allowing or blocking an access path based on whether the path is allowed from the key management bus access rights control module for an access request to the encryption key setting portion transmitted from the application processor module.

Images