CN114676392A - Application trusted authorization method, device and electronic device - Google Patents

Abstract

The invention provides a trusted authorization method and device for application and electronic equipment, relates to the field of hardware equipment, and particularly relates to the field of trusted equipment. The specific implementation scheme is as follows: the method is applied to ARM trusted equipment, and the ARM trusted equipment comprises two protection domains with different authorities on a processor layer: a first protection domain and a second protection domain, comprising the steps of: establishing an incidence relation between the trusted application in the first protection domain and the trusted application in the second protection domain; and controlling other applications in the first protection domain except the trusted application to perform local authorization through the trusted application in the first protection domain.

Description

Application trusted authorization method, device and electronic device

technical field

The present disclosure relates to the technical field of hardware devices, and in particular, to the field of trusted devices.

Background technique

With the rapid development of 5G networks and the maturity of underlying technologies such as cloud native, application deployment and distribution become faster and more efficient, and more and more applications are deployed on ARM devices at edge nodes. Compared with the traditional Internet data center (Internet Data Center, IDC) deployment environment with layer-by-layer protection, the deployment environment of applications on edge devices is more vulnerable to attacks due to relatively weak security construction. Theft, illegal access to equipment. Therefore, higher requirements are placed on the security on the edge side.

SUMMARY OF THE INVENTION

The present disclosure provides a trusted authorization method, apparatus and electronic device for applications.

According to an aspect of the present disclosure, an application trusted authorization method is provided, which is applied to an ARM trusted device. The ARM trusted device includes two protection domains with different permissions at the processor layer: a first protection domain and a second protection domain domain, the method includes the following steps: establishing an association relationship between the trusted application in the first protection domain and the trusted application in the second protection domain; controlling other applications except the trusted application in the first protection domain to pass Trusted applications in the first protection domain perform local authorization.

According to another aspect of the present disclosure, there is provided a trusted authorization device for applications, comprising: an establishment module configured to establish an association between a trusted application in a first protection domain and a trusted application in a second protection domain relationship, wherein the first protection domain and the second protection domain are two protection domains with different permissions included in the processor layer of the ARM trusted device; the control module is configured to control the first protection domain except for trusted applications. Other applications perform local authorization through trusted applications in the first protection domain.

According to another aspect of the present disclosure, there is provided an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor. At least one processor executes the trusted authorization method of the above application to enable the at least one processor to execute.

According to yet another aspect of the present disclosure, there is provided a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the above trusted authorization method of an application.

According to yet another aspect of the present disclosure, a computer program product is provided, including a computer program, which implements the above trusted authorization method for an application when executed by a processor.

It should be understood that what is described in this section is not intended to identify key or critical features of embodiments of the disclosure, nor is it intended to limit the scope of the disclosure. Other features of the present disclosure will become readily understood from the following description.

Description of drawings

The accompanying drawings are used for better understanding of the present solution, and do not constitute a limitation to the present disclosure. in:

1 is a flowchart of an applied trusted authorization method according to an embodiment of the present disclosure;

2 is a schematic structural diagram of an ARM trusted device according to an embodiment of the present disclosure;

Fig. 3 is a startup flowchart of an ARM trusted device according to an embodiment of the present disclosure;

4 is a structural block diagram of an applied trusted authorization device according to an embodiment of the present disclosure;

5 shows a schematic block diagram of an example electronic device 500 that may be used to implement embodiments of the present disclosure.

Detailed ways

Exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, which include various details of the embodiments of the present disclosure to facilitate understanding and should be considered as exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted from the following description for clarity and conciseness.

First of all, some nouns or terms that appear in the process of describing the embodiments of the present application are suitable for the following explanations:

Cloud native is a set of cloud technology product systems based on distributed deployment and unified operation and management of the distributed cloud, and based on technologies such as containers, microservices, and DevOps.

Edge devices, devices that provide an entry point to an enterprise or service provider core network, such as routers, routing switches, integrated access devices, multiplexing devices, and various metro and wide area network access devices.

The Trustzone hardware architecture is designed to provide a security framework that enables devices to defend against the multitude of threats they will encounter. Trustzone technology provides an infrastructure that allows SoC designers to choose from a large number of components that can implement a specific function in a secure environment, rather than providing a fixed and one-size-fits-all security solution.

Kubernetes, a container orchestration engine open sourced by Google, supports automated deployment, large-scale scalability, and application containerized management.

Unix Domain Socket, inter-process communication, is used to implement inter-process communication on the same host.

Transport Layer Security, TLS, a secure transport layer protocol used to provide confidentiality and data integrity between two communicating applications.

As mentioned in the background art, more and more applications are deployed on ARM devices of edge nodes, and the application protection of edge devices is generally considered from the following two aspects:

1) Fingerprint-based device and application authorization deployment for edge devices;

2) The edge device applies central authorization based on remote authentication;

Fingerprint-based device and application authorization on edge devices has the following disadvantages: Since the dimension of fingerprint collection is related to hardware devices, and the hardware is provided by hardware manufacturers, there is no guarantee that the source has not been tampered with. It is difficult to guarantee that an attacker who understands the device firmware will reproduce the fingerprint dimension from the firmware level to achieve the purpose of attack and become a malicious edge node device; in the process, the mode of first collecting fingerprints and then deploying is often adopted, and the timing of application deployment and delivery This creates constraints and does not conform to the cloud-native deployment model.

On edge devices that use centralized authentication, applications need to rely on external service authorization, which puts forward higher requirements for edge devices in terms of network availability and communication security in the edge environment, and increases the attack surface, such as through proxy Bypassing the remote authorization mechanism to achieve the attack.

The existing edge device access and application authorization schemes are still relatively vulnerable to malicious node access and authorization bypassing, and the use of centralized authorization also adds additional attack points.

Aiming at the above-mentioned problems of illegal access to devices and unauthorized use of applications, the present disclosure proposes a solution for edge application activation and authorization based on ARM trusted devices for edge devices, aiming to protect the security access and authorization of edge devices. Trusted authorization for the application.

The solution provided by the present disclosure can solve the access of malicious nodes on the edge and provide trusted applications, and ensure the safe deployment of other applications running on the nodes through the authorization mechanism of trusted applications. The solution also has high scalability, and can expand the access of multiple trusted devices based on this solution, and greatly reduce the adaptation difficulty of upper-layer applications on different devices, and even achieve zero-code adaptation.

The scheme provided by the present disclosure will be described in detail below in conjunction with specific embodiments:

1 is a flowchart of an application trusted authorization method according to an embodiment of the present disclosure. The method is applied to an ARM trusted device, and the ARM trusted device includes two protection domains with different permissions at the processor layer: the first protection domain and a second protection domain, the method includes the following steps:

Step S101, establishing an association relationship between the trusted application in the first protection domain and the trusted application in the second protection domain.

FIG. 2 is a schematic structural diagram of an ARM trusted device according to an embodiment of the present disclosure. As shown in FIG. 2 , ARM provides relevant documents of hardware and firmware, including necessary security requirements for designing a security device. Therefore, the Trustzone capability is generally available on edge devices based on the ARM architecture. Arm Trust-zone is a security solution within the scope of Soc and CPU launched by ARM. The basic principle is that by modifying the original hardware architecture, two protection domains with different permissions are introduced at the processor layer—Secure World (Trustzone OS). , ie the second protection domain above) and the normal world (NormalOS, ie the first protection domain above), the processor only runs in one of these environments at any time. At the same time, the two worlds are isolated by hardware and have different permissions. Applications or operating systems running in the normal world are strictly restricted from accessing the resources of the secure world. Conversely, programs running in the secure world can normally access the normal world. Resources. The hardware isolation and different permissions between the two worlds provide an effective mechanism for protecting application code and data. The solution provided by the embodiments of the present disclosure is to build a set of secure edge device standards based on Trustzone technology. Access and trusted application authorization schemes.

In the structure diagram shown in Figure 2, the authorization relationship before and after is the startup of the trusted application in Normal OS and whether it normally provides the ability to authorize other applications to run after startup depends on whether it is related to the trusted application in Trustzone OS (Figure 2 The Trusty application) generates an association, and this process is called activation.

Step S102, controlling other applications in the first protection domain except the trusted applications to perform local authorization through the trusted applications in the first protection domain.

Whether other applications (generally referring to actual business applications) in Normal OS can run normally when deployed based on Kubernetes after being delivered to the cloud is achieved through local authorization, that is, whether access to trusted applications in Normal OS is authorized credentials.

Through the above method, the problem of malicious node access on edge devices is solved, and by establishing an association relationship between the normal world (Normal OS) and the secure world (Trustzone OS), an authorization mechanism for trusted applications is realized, which can ensure the operation of Secure deployment of other applications on edge devices.

According to an optional embodiment of the present application, performing step S101 to establish an association relationship between a trusted application in the first protection domain and a trusted application in the second protection domain can be achieved by the following methods: The authorization information of the trusted application in the domain is stored in the second protection domain; the root key used to start the trusted application in the first protection domain is stored in the second protection domain.

The association between the trusted applications in the Normal OS and the trusted applications in the Trustzone OS can be embodied in various forms: for example, whether the authorization information (license) of the trusted applications in the Normal OS is stored in the Trustzone OS, or whether to start the Normal OS Whether the root keys of trusted applications in the OS are stored in Trustzone OS.

Therefore, in this step, establishing an association relationship between the trusted application in the Normal OS and the trusted application in the Trustzone OS can be achieved in the following manner: storing the authorization information (license) of the trusted application in the Normal OS in the Trustzone OS , or store the root key for launching trusted applications in Normal OS in Trustzone OS.

In practical applications, the second method is generally adopted, that is, the root key for starting the trusted application in the Normal OS is stored in the Trustzone OS, because the upper-layer application in the Normal OS needs the root key when starting, and the root key is stored in the The Trustzone OS can prevent the communication content from being eavesdropped during the communication between the Normal OS and the Trustzone OS, and can achieve the technical effect of improving data security.

Through the above method, an authorization mechanism for trusted applications in the Trustzone-based Normal OS can be implemented.

According to another optional embodiment of the present application, executing step S102 to control other applications in the first protection domain except the trusted application to perform local authorization through the trusted application in the first protection domain includes the following steps: controlling other applications The application obtains a credential for local authorization from a trusted application in the first protection domain; and performs local authorization for other applications according to the credential.

In some optional embodiments of the present application, controlling other applications to obtain a credential for local authorization from a trusted application in the first protection domain is implemented by the following methods: using an inter-process communication socket and a two-way secure transport layer protocol Get credentials.

In the process of local authorization of other applications (generally referring to actual business applications) other than trusted applications in Normal OS, access to trusted applications in Normal OS is authorized credential. This part of the communication is generally based on inter-process communication Socket (Unix Domain Socket) and two-way security transport layer protocol (Transport Layer Security, TLS) are implemented. The former ensures the efficiency of communication, and the latter ensures the reliability of identity authentication of both parties.

Through the above methods, the secure deployment of trusted applications and business applications in Normal OS is realized.

As an optional embodiment, the ARM trusted device runs encrypted and signed firmware.

In an optional embodiment of the present application, before establishing the association relationship between the trusted application in the first protection domain and the trusted application in the second protection domain, the above method further includes: using a preset private key pair The firmware decrypts and verifies whether the signature of the firmware is consistent with the preset signature; when the firmware is successfully decrypted and the signature of the firmware is consistent with the preset signature, trigger execution to establish the trusted application in the first protection domain and the second The association between trusted applications in the protection domain.

Based on the above implementation alone, there is no guarantee that the device is not a malicious node. The Trustzone capability on ARM devices provides an isolated environment for secure access, ensuring that confidential data can be stored and isolated in the Trustzone, but it cannot be guaranteed that the Trustzone is credible on the current device, and there is still the possibility of forging and cloning the Trustzone partition. A malicious node is created by flashing the Trustzone firmware to an unauthorized device and copying related applications to the new device for authorized operation. Therefore, on the basis of the above-mentioned trustzone function, the above-mentioned technical solutions provided by the present disclosure add the concepts of trusted firmware and trusted boot, that is, the firmware flashed by the device is encrypted and signed, and cannot be used without a private key. It is impossible to implement the clone of the system partition, and it is impossible to flash other firmware on the trusted device. During system startup, the firmware is decrypted and the signature value of the firmware is verified to be consistent.

Fig. 3 is a startup flow chart of an ARM trusted device according to an embodiment of the present disclosure, as shown in Fig. 3, first boot from the device root (Soc BootRom); then decrypt the firmware, and verify the signature of the firmware; If the decryption is successful and the signature verification of the firmware is passed, the kernel is loaded.

The above solution provided by the present disclosure uses the firmware encryption and signature mechanism on the ARM device to realize the reliable source of the firmware flashed into the device, thereby ensuring the trusted access of the node device; The trusted application activation of the normal OS, and the deployment and operation of the business program in the Normal OS are based on the trusted application in the Normal OS, thus realizing the authorized deployment of the business application. And this solution also has considerable universality when migrating different hardware. It only needs to implement the activation strategy for the trusted application in Normal OS to adapt to multiple hardware. The business program in Normal OS can greatly reduce the adaptation workload or zero. Code adaptation.

The technical solution provided by the present disclosure comprehensively considers the complete link of device admission and application deployment. It can protect software assets to run on trusted and authorized edge nodes. At the same time, when more hardware types appear on edge nodes, the threshold for business program adaptation is lowered. Only trusted applications need to be adapted to the underlying authorization implementation of different hardware platforms. , with high flexibility.

In the technical solution of the present disclosure, the acquisition, storage and application of the user's personal information involved are all in compliance with the provisions of relevant laws and regulations, and do not violate public order and good customs.

FIG. 4 is a structural block diagram of a trusted authorization device for an application according to an embodiment of the present disclosure. As shown in FIG. 4 , the device includes:

The establishing module 41 is configured to establish an association relationship between the trusted application in the first protection domain and the trusted application in the second protection domain, wherein the first protection domain and the second protection domain are processed by the ARM trusted device The server layer includes two protection domains with different permissions.

As shown in Figure 2, ARM provides hardware and firmware related documents, including the necessary security requirements for designing security devices. Therefore, the Trustzone capability is generally available on edge devices based on the ARM architecture. Arm Trust-zone is a security solution within the scope of Soc and CPU launched by ARM. The basic principle is that by modifying the original hardware architecture, two protection domains with different permissions are introduced at the processor layer—Secure World (Trustzone OS). , namely the second protection domain above) and the normal world (Normal OS, namely the first protection domain above), the processor only runs in one of these environments at any time. At the same time, the two worlds are isolated by hardware and have different permissions. Applications or operating systems running in the normal world are strictly restricted from accessing the resources of the secure world. Conversely, programs running in the secure world can normally access the normal world. Resources. The hardware isolation and different permissions between the two worlds provide an effective mechanism for protecting application code and data. The solution provided by the present disclosure is to build a set of secure edge device access and Trusted application authorization scheme.

In the structure diagram shown in Figure 2, the authorization relationship before and after is the startup of the trusted application in Normal OS and whether it normally provides the ability to authorize other applications to run after startup depends on whether it is related to the trusted application in Trustzone OS (Figure 2 The Trusty application) generates an association, and this process is called activation.

The control module 42 is configured to control other applications in the first protection domain except the trusted applications to perform local authorization through the trusted applications in the first protection domain.

Whether other applications (generally referring to actual business applications) in Normal OS can run normally when deployed based on Kubernetes after being delivered to the cloud is achieved through local authorization, that is, whether access to trusted applications in Normal OS is authorized credentials.

Through the above device, the problem of malicious node access on the edge device is solved, and the secure deployment of other applications running on the edge device can be ensured through the authorization mechanism of the trusted application.

According to an optional embodiment of the present application, the establishment module 41 includes: a first storage unit, configured to store authorization information of trusted applications in the first protection domain in the second protection domain; a second storage unit, configured to for storing the root key for launching the trusted application in the first protection domain in the second protection domain.

The association between the trusted applications in the Normal OS and the trusted applications in the Trustzone OS can be embodied in various forms: for example, whether the authorization information (license) of the trusted applications in the Normal OS is stored in the Trustzone OS, or whether to start the Normal OS Whether the root keys of trusted applications in the OS are stored in Trustzone OS.

Therefore, establishing an association relationship between a trusted application in the Normal OS and a trusted application in the Trustzone OS can be achieved by: storing the authorization information (license) of the trusted application in the Normal OS in the Trustzone OS, or storing The root keys for launching trusted applications in Normal OS are stored in Trustzone OS.

Through the above device, an authorization mechanism for trusted applications in the Trustzone-based Normal OS can be implemented.

According to another optional embodiment of the present application, the control module 42 includes: a control unit configured to control other applications to obtain credentials for local authorization from trusted applications in the first protection domain; a processing unit configured to Other applications perform local authorization.

In some optional embodiments of the present application, the control unit is further configured to obtain the credential through an inter-process communication socket and a bidirectional secure transport layer protocol.

In the process of local authorization of other applications (generally referring to actual business applications) other than trusted applications in Normal OS, access to trusted applications in Normal OS is authorized credential. This part of the communication is generally based on inter-process communication Socket (Unix Domain Socket) and two-way security transport layer protocol (Transport Layer Security, TLS) are implemented. The former ensures the efficiency of communication, and the latter ensures the reliability of identity authentication of both parties.

Through the above devices, the secure deployment of trusted applications and business applications in Normal OS is realized.

As an optional embodiment, the ARM trusted device runs encrypted and signed firmware.

In some other optional embodiments of the present application, the above-mentioned device further includes: a processing module, configured to decrypt the firmware by using a preset private key, and verify whether the signature of the firmware is consistent with the preset signature; a trigger module, set to In the case that the firmware is successfully decrypted and the signature of the firmware is consistent with the preset signature, the execution is triggered to establish an association relationship between the trusted application in the first protection domain and the trusted application in the second protection domain.

Based on the above implementation alone, there is no guarantee that the device is not a malicious node. The Trustzone capability on ARM devices provides an isolated environment for secure access, ensuring that confidential data can be stored and isolated in the Trustzone, but it cannot be guaranteed that the Trustzone is credible on the current device, and there is still the possibility of forging and cloning the Trustzone partition. A malicious node is created by flashing the Trustzone firmware to an unauthorized device and copying related applications to the new device for authorized operation. Therefore, on the basis of the above-mentioned trustzone function, the above-mentioned technical solutions provided by the present disclosure add the concepts of trusted firmware and trusted boot, that is, the firmware flashed by the device is encrypted and signed, and cannot be used without a private key. It is impossible to implement the clone of the system partition, and it is impossible to flash other firmware on the trusted device. During system startup, the firmware is decrypted and the signature value of the firmware is verified to be consistent.

As shown in Figure 3, first boot from the device root (Soc BootRom); then decrypt the firmware and verify the signature of the firmware; if the firmware decryption is successful and the signature verification of the firmware is passed, the kernel is loaded.

The above-mentioned device provided by the present disclosure uses the mechanism of firmware encryption and signature on the ARM device to realize the reliable source of the firmware flashed into the device, thereby ensuring the trusted access of the node device; The trusted application activation of the normal OS, and the deployment and operation of the business program in the Normal OS are based on the trusted application in the Normal OS, thus realizing the authorized deployment of the business application. And this solution also has considerable universality when migrating different hardware. It only needs to implement the activation strategy for the trusted application in Normal OS to adapt to multiple hardware. The business program in Normal OS can greatly reduce the adaptation workload or zero. Code adaptation.

The technical solution provided by the present disclosure comprehensively considers the complete link of device admission and application deployment. It can protect software assets to run on trusted and authorized edge nodes. At the same time, when more hardware types appear on edge nodes, the threshold for business program adaptation is lowered. Only trusted applications need to be adapted to the underlying authorization implementation of different hardware platforms. , with high flexibility.

According to embodiments of the present disclosure, the present disclosure also provides an electronic device, a readable storage medium, and a computer program product.

5 shows a schematic block diagram of an example electronic device 500 that may be used to implement embodiments of the present disclosure. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are by way of example only, and are not intended to limit implementations of the disclosure described and/or claimed herein.

As shown in FIG. 5 , the device 500 includes a computing unit 501 that can be executed according to a computer program stored in a read only memory (ROM) 502 or loaded from a storage unit 508 into a random access memory (RAM) 503 Various appropriate actions and handling. In the RAM 503, various programs and data necessary for the operation of the device 500 can also be stored. The computing unit 501 , the ROM 502 , and the RAM 503 are connected to each other through a bus 504 . An input/output (I/O) interface 505 is also connected to bus 504 .

Various components in the device 500 are connected to the I/O interface 505, including: an input unit 506, such as a keyboard, mouse, etc.; an output unit 507, such as various types of displays, speakers, etc.; a storage unit 508, such as a magnetic disk, an optical disk, etc. ; and a communication unit 509, such as a network card, a modem, a wireless communication transceiver, and the like. The communication unit 509 allows the device 500 to exchange information/data with other devices through a computer network such as the Internet and/or various telecommunication networks.

Computing unit 501 may be various general-purpose and/or special-purpose processing components with processing and computing capabilities. Some examples of computing units 501 include, but are not limited to, central processing units (CPUs), graphics processing units (GPUs), various specialized artificial intelligence (AI) computing chips, various computing units that run machine learning model algorithms, digital signal processing processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as the trusted authorization method of the application. For example, in some embodiments, the trusted authorization method of an application may be implemented as a computer software program tangibly embodied on a machine-readable medium, such as storage unit 508 . In some embodiments, part or all of the computer program may be loaded and/or installed on device 500 via ROM 502 and/or communication unit 509 . When the computer program is loaded into RAM 503 and executed by computing unit 501, one or more steps of the trusted authorization method of the application described above may be performed. Alternatively, in other embodiments, the computing unit 501 may be configured to execute the trusted authorization method of the application by any other suitable means (eg, by means of firmware).

Various implementations of the systems and techniques described herein above may be implemented in digital electronic circuitry, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips system (SOC), load programmable logic device (CPLD), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include being implemented in one or more computer programs executable and/or interpretable on a programmable system including at least one programmable processor that The processor, which may be a special purpose or general-purpose programmable processor, may receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device an output device.

Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, performs the functions/functions specified in the flowcharts and/or block diagrams. Action is implemented. The program code may execute entirely on the machine, partly on the machine, partly on the machine and partly on a remote machine as a stand-alone software package or entirely on the remote machine or server.

In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in connection with the instruction execution system, apparatus or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media may include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media would include one or more wire-based electrical connections, portable computer disks, hard disks, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), fiber optics, compact disk read only memory (CD-ROM), optical storage, magnetic storage, or any suitable combination of the foregoing.

To provide interaction with a user, the systems and techniques described herein may be implemented on a computer having a display device (eg, a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user ); and a keyboard and pointing device (eg, a mouse or trackball) through which a user can provide input to the computer. Other kinds of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (eg, visual feedback, auditory feedback, or tactile feedback); and can be in any form (including acoustic input, voice input, or tactile input) to receive input from the user.

The systems and techniques described herein may be implemented on a computing system that includes back-end components (eg, as a data server), or a computing system that includes middleware components (eg, an application server), or a computing system that includes front-end components (eg, a user computer having a graphical user interface or web browser through which a user may interact with implementations of the systems and techniques described herein), or including such backend components, middleware components, Or any combination of front-end components in a computing system. The components of the system may be interconnected by any form or medium of digital data communication (eg, a communication network). Examples of communication networks include: Local Area Networks (LANs), Wide Area Networks (WANs), and the Internet.

A computer system can include clients and servers. Clients and servers are generally remote from each other and usually interact through a communication network. The relationship of client and server arises by computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, a distributed system server, or a server combined with blockchain.

It should be understood that steps may be reordered, added or deleted using the various forms of flow shown above. For example, the steps described in the present disclosure can be executed in parallel, sequentially, or in different orders. As long as the desired results of the technical solutions disclosed in the present disclosure can be achieved, there is no limitation herein.

The above-mentioned specific embodiments do not constitute a limitation on the protection scope of the present disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent replacements, and improvements made within the spirit and principles of the present disclosure should be included within the protection scope of the present disclosure.

Claims (15)

1. A trusted authorization method of an application is applied to an ARM trusted device, and the ARM trusted device comprises two protection domains with different authorities in a processor layer: a first protection domain and a second protection domain, the method comprising the steps of:

establishing an association between a trusted application in the first protected domain and a trusted application in the second protected domain;

and controlling other applications in the first protection domain except the trusted application to perform local authorization through the trusted application in the first protection domain.

2. The method of claim 1, wherein the establishing an association between the trusted application in the first protected domain and the trusted application in the second protected domain comprises at least one of:

storing authorization information for a trusted application in the first protected domain in the second protected domain;

storing a root key for launching a trusted application in the first protected domain in the second protected domain.

3. The method of claim 1, wherein the controlling other applications in the first protected domain other than the trusted application to be locally authorized by the trusted application in the first protected domain comprises:

controlling the other application to obtain credentials for local authorization from a trusted application in the first protected domain;

and locally authorizing the other applications according to the certificate.

4. The method of claim 3, wherein the controlling the other application to obtain credentials for local authorization from a trusted application in the first protected domain comprises:

and acquiring the certificate through an interprocess communication socket and a two-way secure transport layer protocol.

5. The method of any of claims 1 to 4, further comprising:

And the ARM trusted equipment runs encrypted and signed firmware.

6. The method of claim 5, wherein prior to the establishing an association between the trusted application in the first protected domain and the trusted application in the second protected domain, the method further comprises:

decrypting the firmware by using a preset private key and verifying whether the signature of the firmware is consistent with a preset signature;

and under the condition that the firmware is successfully decrypted and the signature of the firmware is consistent with the preset signature, triggering and establishing an association relationship between the trusted application in the first protection domain and the trusted application in the second protection domain.

7. A trusted authority for an application, comprising:

the device comprises an establishing module, a judging module and a judging module, wherein the establishing module is set to establish an incidence relation between a trusted application in a first protection domain and a trusted application in a second protection domain, and the first protection domain and the second protection domain are two protection domains with different authorities, which are included in a processor layer of ARM trusted equipment;

a control module configured to control other applications in the first protected domain except the trusted application to perform local authorization through the trusted application in the first protected domain.

8. The apparatus of claim 7, wherein the establishing means comprises:

a first storage unit configured to store authorization information of a trusted application in the first protected domain in the second protected domain;

a second storage unit arranged to store a root key for launching a trusted application in the first protected domain in the second protected domain.

9. The apparatus of claim 7, wherein the control module comprises:

a control unit configured to control the other application to obtain a credential for local authorization from a trusted application in the first protected domain;

and the processing unit is arranged for carrying out local authorization on the other applications according to the certificate.

10. The apparatus of claim 9, wherein the control unit is further configured to obtain the credentials via an interprocess communication socket and a two-way secure transport layer protocol.

11. The apparatus of any of claims 7 to 10, the ARM trusted device running encrypted and signed firmware.

12. The apparatus of claim 11, wherein the apparatus further comprises:

the processing module is used for decrypting the firmware by using a preset private key and verifying whether the signature of the firmware is consistent with a preset signature or not;

And the triggering module is used for triggering and executing the establishment of the association relationship between the trusted application in the first protection domain and the trusted application in the second protection domain under the condition that the firmware is successfully decrypted and the signature of the firmware is consistent with the preset signature.

13. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform a trusted authorization method for an application as claimed in any of claims 1-6.

14. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform a trusted authorization method of an application according to any one of claims 1-6.

15. A computer program product comprising a computer program which, when executed by a processor, implements a trusted authorization method for an application according to any one of claims 1-6.

Images