WO2017161569A1 - 访问控制的方法、装置和系统 - Google Patents

访问控制的方法、装置和系统 Download PDF

Info

Publication number
WO2017161569A1
WO2017161569A1 PCT/CN2016/077365 CN2016077365W WO2017161569A1 WO 2017161569 A1 WO2017161569 A1 WO 2017161569A1 CN 2016077365 W CN2016077365 W CN 2016077365W WO 2017161569 A1 WO2017161569 A1 WO 2017161569A1
Authority
WO
WIPO (PCT)
Prior art keywords
access
application
trustzone
user information
module
Prior art date
Application number
PCT/CN2016/077365
Other languages
English (en)
French (fr)
Inventor
王永辉
Original Assignee
深圳前海达闼云端智能科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 深圳前海达闼云端智能科技有限公司 filed Critical 深圳前海达闼云端智能科技有限公司
Priority to CN201680002731.7A priority Critical patent/CN107111511B/zh
Priority to PCT/CN2016/077365 priority patent/WO2017161569A1/zh
Publication of WO2017161569A1 publication Critical patent/WO2017161569A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45587—Isolation or security of virtual machine instances

Definitions

  • the present invention relates to the field of virtualization technologies, and in particular, to a method, apparatus, and system for access control.
  • TrustZone is ARM's architecture for consumer electronics security and is an extension of the security system throughout the system design process, with the goal of protecting against a wide range of specific threats to devices, including those from malware or devices. Threat.
  • Access control is one of the important scenarios in scenarios where TrustZone is required to provide protection.
  • the payment application in the architecture shown in Figure 1 needs to access the TrustZone and run in the TrustZone to implement the payment function of the payment application.
  • the application generates an access request to access the TrustZone, and the access request includes the identifier of the payment application; the TrustZone obtains the access.
  • the request response module responds to the access request according to the identifier of the payment application in the access request to provide protection during the implementation of the payment function.
  • any virtual machine can access the TrustZone by sending an access request, and the function is that each virtual machine has the same access to the TrustZone.
  • different virtual machines require different access rights to flexibly control access to virtual machines.
  • an embodiment of the present invention provides a method, an apparatus, and a system for access control.
  • an embodiment of the present invention provides a method for access control, where the method includes:
  • the access request is sent to the request response module of the TrustZone.
  • the application is fed back a first message that cannot access the TrustZone.
  • the determining, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone includes:
  • the virtual machine monitor determines that the application can access the TrustZone according to the preset first access policy, the virtual machine identifier, and the application identifier.
  • the method further includes:
  • the Hypervisor obtains user information, and passes the first verification of the user information
  • the user information is information of a user who uses the application.
  • the hypervisor feeds back to the application a second message that cannot access the TrustZone.
  • the hypervisor obtains user information, including:
  • the hypervisor invokes the first user information collection device to obtain user information
  • the first user information collection device is called by each module in the terminal where the method is located.
  • the access request further includes user information
  • the hypervisor obtains user information, including:
  • the hypervisor acquires user information in the access request.
  • the determining, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone includes:
  • the verification module of the TrustZone determines that the application can access the TrustZone according to the preset first access policy, the virtual machine identifier, and the application identifier.
  • the method further includes:
  • the verification module acquires user information and passes the second verification of the user information.
  • the verification module feeds back to the application a third message that cannot access the TrustZone.
  • the verification module acquires user information, including:
  • the verification module invokes the second user information collection device to obtain user information
  • the second user information collection device is called by each module in the TrustZone.
  • the access request further includes user information
  • the verification module acquires user information, including:
  • the verification module acquires user information in the access request.
  • the determining, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone includes:
  • the hypervisor according to a preset first access policy, the virtual machine identifier, and the application Identifying that the application is capable of accessing the TrustZone.
  • the method further includes:
  • the verification module determines that the application can access the TrustZone according to the preset second access policy, the virtual machine identifier, and the application identifier.
  • the method further includes:
  • the verification module acquires user information and passes the third verification of the user information.
  • the verification module feeds back to the application a fourth message that cannot access the TrustZone.
  • the verification module acquires user information, including:
  • the verification module invokes the second user information collection device to obtain user information.
  • the access request further includes user information
  • the verification module acquires user information, including:
  • the verification module acquires user information in the access request.
  • an embodiment of the present invention provides an apparatus for access control, where the apparatus includes:
  • a receiving submodule configured to receive an access request sent by an application to access a TrustZone, where the access request includes a virtual machine identifier where the application is located, and an application identifier of the application;
  • a first determining submodule configured to determine, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone;
  • a sending submodule configured to send an access request received by the receiving submodule to the request response module of the TrustZone.
  • the device further includes:
  • a first feedback submodule configured to, when determining that the application cannot access the TrustZone, feed back to the application a first message that cannot access the TrustZone.
  • the first determining sub-module is located in the virtual machine monitor hypervisor, and is configured to determine, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can Access to the TrustZone.
  • the device further includes:
  • a first obtaining submodule where the first obtaining submodule is located in the hypervisor for acquiring user information
  • first verification sub-module located in the hypervisor, and is configured to pass the first verification of the user information acquired by the first acquisition sub-module;
  • the user information is information of a user who uses the application.
  • the device further includes:
  • a second feedback sub-module where the second feedback sub-module is located in the hypervisor, and is configured to feed back, to the application, a second message that cannot access the TrustZone when the first verification fails.
  • the first acquiring submodule is configured to invoke the first user information collecting device to obtain user information.
  • the first user information collection device is called by each module in the terminal where the method is located.
  • the access request further includes user information
  • the first obtaining submodule is configured to obtain user information in the access request.
  • the first determining sub-module is located in the verification module of the TrustZone, and is configured to determine, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone.
  • the device further includes:
  • a second acquisition sub-module where the second acquisition sub-module is located in the verification module, and is used to acquire user information
  • the second verification sub-module is located in the verification module, and is configured to pass the second verification of the user information acquired by the second acquisition sub-module.
  • the device further includes:
  • a third feedback sub-module where the third feedback sub-module is located in the verification module, and is configured to feed back, to the application, a third message that cannot access the TrustZone when the second verification fails.
  • the second acquiring submodule is configured to invoke the second user information collection device to acquire Household information
  • the second user information collection device is called by each module in the TrustZone.
  • the access request further includes user information
  • the second obtaining submodule is configured to obtain user information in the access request.
  • the first determining sub-module is located in the hypervisor, and is configured to determine, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone.
  • the device further includes:
  • a second determining sub-module configured to determine, according to the preset second access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone.
  • the device further includes:
  • a third acquisition sub-module where the third acquisition sub-module is located in the verification module, and is used to acquire user information
  • the device further includes:
  • a fourth feedback sub-module where the fourth feedback sub-module is located in the verification module, and is configured to feed back, to the application, a fourth message that cannot access the TrustZone when the third verification fails.
  • the third obtaining submodule is configured to invoke the second user information collecting device to obtain user information.
  • the access request further includes user information
  • the third obtaining submodule is configured to obtain user information in the access request.
  • an embodiment of the present invention provides a system for access control, where the system includes: at least one virtual machine, a TrustZone, and an access control device;
  • An application running in the virtual machine when the application accesses the TrustZone, sending an access request to the access control device to access the TrustZone, where the access request includes the The virtual machine identifier where the application is located, and the application identifier of the application;
  • the access control device is configured to receive the access request, determine, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone; Request to send to the TrustZone's request response module;
  • the TrustZone's request response module is responsive to the access request.
  • the device for access control is further configured to: when it is determined that the application cannot access the TrustZone, feed back, to the application, a first message that cannot access the TrustZone.
  • system further includes: a virtual machine monitor hypervisor;
  • the access control device is located in the hypervisor.
  • the device for access control is located in the TrustZone.
  • system further includes: a hypervisor
  • the access control device includes a first access control sub-device and a second access control sub-device;
  • the first access control sub-device is located in the hypervisor, and is configured to determine, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone;
  • the second access control sub-device is located in the TrustZone, and after the first access control sub-device determines that the application can access the TrustZone, according to a preset second access policy, the virtual And identifying the application identifier, the application is capable of accessing the TrustZone; and sending the access request to the request response module of the TrustZone.
  • the access request includes the virtual machine identifier of the application, the application identifier of the application, and determining that the application can access the TrustZone according to the preset access policy, the virtual machine identifier, and the application identifier;
  • the request response module sent by the access request to the TrustZone implements flexible control over the access rights of different virtual machine identifiers and different application identifiers.
  • FIG. 1 is a schematic diagram of a system architecture provided by the present invention.
  • FIG. 2 is a schematic diagram showing another system architecture provided by the present invention.
  • FIG. 3 is a schematic diagram showing another system architecture provided by the present invention.
  • Embodiment 4 is a schematic structural diagram of a system provided in Embodiment 1 of the present invention.
  • FIG. 5 is a schematic flowchart diagram of a method for access control according to Embodiment 1 of the present invention.
  • FIG. 6 is a schematic structural diagram of a system provided in Embodiment 2 of the present invention.
  • FIG. 7 is a schematic flowchart diagram of a method for access control provided in Embodiment 2 of the present invention.
  • FIG. 8 is a schematic flowchart diagram of a method for access control according to Embodiment 3 of the present invention.
  • FIG. 9 is a schematic flowchart diagram of a method for access control according to Embodiment 3 of the present invention.
  • FIG. 10 is a schematic structural diagram of an apparatus for access control according to Embodiment 4 of the present invention.
  • FIG. 11 is a schematic structural diagram of another apparatus for access control according to Embodiment 4 of the present invention.
  • FIG. 12 is a schematic structural diagram of a system for access control according to Embodiment 5 of the present invention.
  • FIG. 13 is a schematic structural diagram of another access control system according to Embodiment 5 of the present invention.
  • FIG. 14 is a schematic structural diagram of a system for access control according to Embodiment 6 of the present invention.
  • FIG. 15 is a schematic structural diagram of a system for access control according to Embodiment 7 of the present invention.
  • FIG. 16 is a schematic structural diagram of another access control system according to Embodiment 7 of the present invention.
  • the present invention provides a solution, which can be in the smart terminal, and the smart terminal can be a smart phone, an intelligent robot, or a tablet.
  • the present invention does not limit the specific product of the smart terminal as long as it includes at least one virtual machine, TrustZone, and can communicate through the network.
  • the core of the solution provided by the present invention is to provide an architecture including at least one virtual machine 301, access control device 302, and TrustZone 303, as shown in FIG.
  • access control devices can implement row-flexible control of access rights for different virtual machine identities and different application identities.
  • an application is run in the virtual machine 301.
  • the application sends an access request to the access control device 302 to access the TrustZone 303, where the access request includes the application.
  • the access control device 302 is configured to receive an access request, determine, according to the preset first access policy, the virtual machine identifier and the application identifier in the access request, the request that the application can access the TrustZone 303 and send the access request to the TrustZone 303. a response module, thereby implementing a technical effect of flexibly controlling access rights of different applications in different virtual machines 301 according to the virtual machine identifier and the application identifier;
  • the TrustZone 303 is located in the CPU (Central Processing Unit), and the request response module of the TrustZone 303 responds to the access request after receiving the access request.
  • CPU Central Processing Unit
  • the device 302 for access control in the architecture shown in FIG. 3 has various specific implementations in actual application.
  • the access control device 302 is implemented in the Hypervisor
  • the access control device 302 is implemented in the TrustZone 303
  • the access control device 302 is implemented in the Hypervisor and the TrustZone 303 as an example.
  • the present application provides a method for access control.
  • the specific implementation architecture of the access control device 302 located in the Hypervisor is as shown in FIG. 4, including:
  • Hypervisor An access control device is run on the Hypervisor, and the access control device performs the access control method provided by the embodiment, and the first access policy is stored on the hypervisor, and the TrustZone access to the application in the VM can be accessed through the first access policy. Access request for access policy judgment, thereby achieving technical effects of flexible control according to access rights of different VMs and different applications;
  • the CPU includes a TrustZone, and the TrustZone includes a request response module, which can respond to the access request after receiving an access request sent by the application in the VM.
  • the TrustZone operating system is running in the TrustZone.
  • the TrustZone operating system includes authentication modules for identity authentication, communication modules for communication, and other templates. This embodiment does not limit the specific modules included in the TrustZone.
  • the access control device is running on the hypervisor, and the first access policy is stored on the hypervisor.
  • the first access policy may be stored in the device for access control, or may be stored in the device for access control.
  • FIG. 4 is only used as an example in the device that is stored in the access control in the first access policy. The specific storage location of the first access policy is defined.
  • the name of the request response module is only an indication. In the specific implementation, it may also be referred to as another name. Regardless of the name, the module that responds to the access request function can be considered as the request response module of this embodiment. If in a practical application, multiple modules jointly implement the response access request function, multiple modules may be considered as sub-modules of the request response module of this embodiment.
  • the first user information collecting device may be connected to the CPU, and the first user information collecting device may be called by each module in the architecture shown in FIG. 4.
  • the first user information collection device includes but is not limited to: a hard keyboard, an iris scanner, a card reader, a U shield storing user fingerprint information, a fingerprint scanner, and the like.
  • the above-mentioned "first” is only a number, and is used for distinguishing user information collection devices connected by different devices, which has no practical significance.
  • Example 1 The payment application 1 initiates the access request 1 to implement the payment function 1 in the TrustZone, wherein the payment application 1 authenticates the user identity by using a fingerprint method, and the virtual machine identifier of the enterprise VM is OS1, and the application identifier of the payment application 1 is ID1. .
  • Example 2 The instant messaging application 2 initiates an access request 2 to implement the payment function 2 in the TrustZone, wherein the virtual machine identifier of the enterprise VM is OS1 and the application identifier of the instant chat application 2 is ID2.
  • Example 3 The payment application 3 initiates an access request 3 to implement the payment function 3 in the TrustZone, wherein the virtual machine identifier of the personal VM is OS2 and the application identifier of the payment application 3 is ID3.
  • the payment application 1 and the payment application 3 may be the same application or different applications. This embodiment does not limit the relationship between the payment application 1 and the payment application 3.
  • the payment function 1 and the payment function 3 may be the same function or different functions. This embodiment does not limit the relationship between the payment application 1 and the payment application 3.
  • ID1 and ID3 may be the same or different. This embodiment does not limit the relationship between ID1 and ID3.
  • the hypervisor receives an access request sent by the application to access the TrustZone;
  • the access request includes the virtual machine identifier where the application is located, and the application identifier of the application.
  • the access request may include other information such as payment amount, payment object, payment description, remarks, etc. according to the specific needs of the application.
  • the execution body of this step is Can be a hypervisor.
  • Example 1 The Hypervisor obtains an access request 1 sent by the payment application 1, and the access request 1 includes OS1, ID1.
  • Example 2 The Hypervisor obtains an access request 2 sent by the instant chat application 2, and the access request 2 includes OS1, ID2.
  • Example 3 The Hypervisor obtains an access request 3 sent by the payment application 3, and the access request 3 includes OS3, ID3.
  • the Hypervisor determines whether the application can access the TrustZone according to the preset first access policy, the virtual machine identifier, and the application identifier. If the TrustZone can be accessed, the step 503 is performed, and if the TrustZone is not accessed, the step 504 is performed;
  • the first access policy may be automatically obtained from the network, or may be obtained through a human-machine interface, and may be obtained by using other methods. This embodiment does not limit the manner in which the first access policy is obtained.
  • the first access policy can be changed, if there are multiple first access policies, you can choose to obtain the latest access policy, or you can select the first access policy according to the preset rules.
  • example 1 Hypervisor According to policy 1, it can be determined that payment application 1 can access TrustZone.
  • Example 2 Hypervisor According to policy 2, it can be determined that the instant chat application 2 cannot access the TrustZone.
  • Example 3 Hypervisor According to policy 3, it can be determined that payment application 3 cannot access TrustZone.
  • the hypervisor sends an access request to the request response module of the TrustZone;
  • Example 1 the Hypervisor sends an access request 1 to the request response module of TrustZone.
  • the first message is used to describe that the application cannot access the TrustZone.
  • the content may include: the specific reason that the virtual machine cannot access the TrustZone, or the application of the virtual machine does not have the permission to access the TrustZone.
  • Example 2 The hypervisor feeds back to the application the first message that cannot access the TrustZone.
  • the first message describes that the instant messenger application 2 in the enterprise VM does not have access to the TrustZone.
  • Example 3 The Hypervisor feeds back to the application the first message that cannot access the TrustZone.
  • the first message describes the individual VM's access to the TrustZone.
  • the hypervisor may perform the following steps after performing step 502 and determining that the application can access the TrustZone, and before performing the step 503 to send the access request to the request response module of the TrustZone:
  • Step 1.1 The Hypervisor obtains user information
  • the user information is information of a user who uses the application
  • the hypervisor can obtain user information in one of two ways:
  • the hypervisor invokes the first user information collection device to obtain the user information
  • the hypervisor obtains the user information in the access request.
  • Example 1 the Hypervisor invokes the first user information collection device (for example, a U shield with a user fingerprint information, a fingerprint scanner, etc.) to obtain user fingerprint information; or, when the access request further includes user information (for example, user fingerprint information) The Hypervisor obtains the user fingerprint information in the access request.
  • the first user information collection device for example, a U shield with a user fingerprint information, a fingerprint scanner, etc.
  • the Hypervisor obtains the user fingerprint information in the access request.
  • Step 1.2 The Hypervisor performs the first verification on the user information, if the first verification is passed, step 503 is performed, and if the first verification fails, step 1.3 is performed;
  • the user information can be verified according to the verification method of the existing user information. For example, step 1.1
  • the user fingerprint information obtained in the matching is matched with the preset standard fingerprint information of the user. If the matching is successful, the first verification is passed. If the matching is unsuccessful, the first verification fails.
  • Step 1.3 The Hypervisor feeds back to the application the second message that cannot access the TrustZone.
  • the second message is used to describe that the application cannot access the TrustZone, and the content may include: a specific reason that cannot be accessed, such as the identity verification fails.
  • first”, “second”, and the like in this embodiment and subsequent embodiments describe messages, information collection devices, authentication, and access policies, but “first”, “second”, etc. It is only used to distinguish messages, information collection devices, authentication, and access policies from each other, and has no other substantive meaning. That is, the first message and the second message may be the same or different, and the first access policy and the second access policy may be the same or different.
  • the Hypervisor receives the access request sent by the application to access the TrustZone.
  • the access request includes the virtual machine identifier of the application, the application identifier of the application, and determines that the application can access the TrustZone according to the preset access policy, the virtual machine identifier, and the application identifier.
  • Sending the access request to the TrustZone request response module enables the Hypervisor to flexibly control the access rights of different VM IDs and different application IDs.
  • the present application provides a method for access control.
  • the specific implementation architecture of the access control device 302 in the TrustZone is shown in Figure 6, including:
  • Hypervisor After receiving the access request sent by the application to access the TrustZone, the Hypervisor forwards the access request to the access control device.
  • TrustZone is included on the CPU, and the verification module and request response are included in the TrustZone.
  • the module meanwhile, has a first access policy stored on the TrustZone.
  • the access control device runs on the authentication module, and the access control device performs the access control method provided by the embodiment, and the verification module can obtain the first access policy stored by the TrustZone, and the access request can be accessed through the first access policy.
  • the request response module may respond to the access request after receiving the access request sent by the application in the VM.
  • the TrustZone operating system runs on the TrustZone.
  • the TrustZone operating system includes authentication modules for identity authentication, communication modules for communication, and other templates.
  • the second user information collection device can be connected to the TrustZone.
  • the second user information collection device can only be called by each module of the TrustZone in the architecture shown in FIG. 6, and cannot be other in the architecture shown in FIG. 6. Module call.
  • the second user information collection device includes but is not limited to: a hard keyboard, an iris scanner, a card reader, a U shield storing user fingerprint information, a fingerprint scanner, and the like.
  • the access control device is running on the TrustZone, and the first access policy is stored on the TrustZone.
  • the first access policy may be stored in the device for access control, or may be stored outside the device for access control.
  • FIG. 6 is only used as an example for the first access policy to be stored in the device for access control. The specific storage location of the first access policy is defined.
  • the third embodiment of the embodiment shown in FIG. 5 is taken as an example for specific description.
  • the Hypervisor receives an access request sent by the application to access the TrustZone, and forwards the access request to the verification module of the TrustZone;
  • the access request includes the virtual machine identifier where the application is located, and the application identifier of the application.
  • the access request may include other information such as payment amount, payment object, payment description, remarks, etc. according to the specific needs of the application.
  • the verification module of the TrustZone receives the access request, according to the preset first access policy, virtual Proxy identification and application identification, to determine whether the application can access the TrustZone, if the TrustZone can be accessed, go to step 703, if you can not access the TrustZone, go to step 704;
  • the verification module according to the policy 1 can determine that the payment application 1 can access the TrustZone.
  • Example 2 The verification module can determine that the instant chat application 2 cannot access the TrustZone according to the policy 2.
  • Example 3 The verification module According to policy 3, it can be determined that the payment application 3 cannot access the TrustZone.
  • the verification module sends an access request to the request response module of the TrustZone;
  • Example 1 the verification module sends an access request 1 to the request response module of TrustZone.
  • the verification module feeds back to the application that the first message of the TrustZone cannot be accessed.
  • the verification module can first feed back to the hypervisor the first message that cannot access the TrustZone. After receiving the first message, the hypervisor forwards the first message to the application.
  • step 702 the verification module performs step 702 and determines that the application can access the TrustZone
  • step 703 the following steps may be performed.
  • Step 2.1 The verification module acquires user information
  • the verification module can obtain user information by using one of the following three methods:
  • the verification module calls the first user information collection device to obtain the user information.
  • the first user information collection device since the first user information collection device is connected to the terminal, and the first user information collection device can be called by each module in the terminal, if a module in the terminal is not secure, it may be The user information collected by the first user information collection device is falsified by the unsafe module before the verification module obtains the information, and the accuracy of the user information acquired by the verification module is reduced.
  • the verification module invokes the second user information collection device.
  • the second user information collection device is directly connected to the TrustZone, and the second user information collection device can only be called by each module in the TrustZone, the user information can be prevented from being tampered with before the verification module obtains the situation. Improve the accuracy of the user information obtained by the verification module.
  • the verification module acquires the user information in the access request.
  • the verification module calls the second user information collection device (for example, a U shield with a user fingerprint information, a fingerprint scanner, etc.) to obtain user fingerprint information.
  • the second user information collection device for example, a U shield with a user fingerprint information, a fingerprint scanner, etc.
  • Step 2.2 The verification module performs a second verification on the user information, if the second verification is passed, step 703 is performed, and if the second verification fails, step 2.3 is performed;
  • Step 2.3 The verification module feeds back to the application a third message that cannot access the TrustZone.
  • the third message is used to describe that the application cannot access the TrustZone, and the content may include: a specific reason that cannot be accessed, such as the identity verification fails.
  • the verification module can first feed back to the hypervisor a third message that cannot access the TrustZone. After receiving the third message, the hypervisor forwards the third message to the application.
  • the authentication module of the TrustZone receives the access request sent by the application to access the TrustZone.
  • the access request includes the virtual machine identifier of the application, the application identifier of the application, and determines the application according to the preset access policy, the virtual machine identifier, and the application identifier. Accessing the TrustZone; sending the access request to the TrustZone's request response module, which enables the authentication module to flexibly control the access rights of different virtual machine identifiers and different application identifiers.
  • the present application provides a method of access control for the specific manner in which the access control device 302 in the architecture shown in FIG. 3 is implemented in both the Hypervisor and the TrustZone 303.
  • the access control device 302 includes: a first access control sub-device and a second access control sub-device, the first access control sub-device is located in the Hypervisor, and the second access control sub-device is located in the TrustZone 303, Hypervisor and TrustZone perform dual access policy judgments, enabling technical effects that are flexibly controlled based on access rights of different VMs and different applications.
  • the architecture includes:
  • Hypervisor A first access policy is stored on the Hypervisor, and the first access control sub-device is run on the hypervisor.
  • the first access control sub-device can perform an access policy judgment on the access request of the TrustZone sent by the application in the VM by using the first access policy. Thereby performing the first access control;
  • the CPU includes TrustZone.
  • the TrustZone includes a verification module and a request response module.
  • the second access policy is stored on the TrustZone.
  • the TrustZone operating system runs on the TrustZone.
  • the TrustZone operating system includes authentication modules for identity authentication, communication modules for communication, and other templates.
  • a second access control sub-device is run on the verification module, and the second access control sub-device can perform an access policy judgment on the access request for accessing the TrustZone sent by the application in the VM by using the second access policy, thereby performing re-access control.
  • first user information collection device can be connected to the CPU, and the second user information collection device can also be connected to the TrustZone.
  • the first access control sub-device runs on the hypervisor, and the first access policy is stored on the hypervisor.
  • the first access policy may be stored in the first access control sub-device, or may be stored in the first access control sub-device.
  • FIG. 8 is only displayed in the first access control sub-device by using the first access policy as an example. The specific storage location of the first access policy is not implemented in the embodiment. Set to limit.
  • a second access control sub-device is running on the TrustZone, and a second access policy is stored on the TrustZone.
  • the second access policy may be stored in the second access control sub-device, or may be stored in the second access control sub-device.
  • FIG. 8 is only displayed in the second access control sub-device as the second access policy. The embodiment does not limit the specific storage location of the second access policy in actual application.
  • the third embodiment of the embodiment shown in FIG. 5 is taken as an example for specific description.
  • the hypervisor receives an access request sent by the application to access the TrustZone;
  • the access request includes a virtual machine identifier where the application is located, and an application identifier of the application;
  • step 501 The specific implementation of this step is the same as that of step 501. For details, see step 501, and details are not described herein again.
  • the Hypervisor determines whether the application can access the TrustZone according to the preset first access policy, the virtual machine identifier, and the application identifier. If the TrustZone can be accessed, the steps 904 to 907 are performed, and if the TrustZone cannot be accessed, the step 903 is performed;
  • step 502 The specific implementation of this step is the same as that of step 502. For details, see step 502, and details are not described herein again.
  • step 504 The specific implementation of this step is the same as that of step 504. For details, see step 504, and details are not described herein again.
  • the Hypervisor forwards the access request to the verification module of the TrustZone;
  • the verification module determines, according to the preset second access policy, the virtual machine identifier, and the application identifier, whether the application can access the TrustZone, if the TrustZone can be accessed, step 906 is performed, and if the TrustZone cannot be accessed, step 907 is performed;
  • the second access policy may be the same as the first access policy in step 902, or may be different.
  • the verification module according to the policy 4 can determine that the payment application 1 can access the TrustZone.
  • Example 2 The verification module can determine that the instant chat application 2 cannot access the TrustZone according to the policy 5.
  • Example 3 The verification module can determine that the payment application 3 cannot access the TrustZone according to the policy 6.
  • the verification module sends an access request to the request response module of the TrustZone;
  • step 703 The specific implementation of this step is the same as that of step 703. For details, see step 703, and details are not described herein again.
  • the verification module feeds back to the application that the first message of the TrustZone cannot be accessed.
  • step 704. The specific implementation of this step is the same as step 704. For details, see step 704, and details are not described herein again.
  • step 905 the verification module performs step 905 and determines that the application can access the TrustZone
  • step 906 the following steps may be performed.
  • Step 3.1 The verification module obtains user information
  • step 2.1 The specific implementation of this step is the same as that in step 2.1. For details, see step 2.1, and details are not described here.
  • Step 3.2 The verification module performs third verification on the user information, if the third verification is passed, step 906 is performed, and if the third verification fails, step 3.3 is performed;
  • Step 3.3 The verification module feeds back to the application the fourth message that cannot access the TrustZone.
  • the fourth message is used to describe that the application cannot access the TrustZone, and the content may include: a specific reason that cannot be accessed, such as the identity verification fails.
  • the verification module can first feed back to the hypervisor the fourth message that cannot access the TrustZone. After receiving the fourth message, the hypervisor forwards the fourth message to the application.
  • the Hypervisor receives the access request sent by the application to access the TrustZone.
  • the access request includes the virtual machine identifier of the application, the application identifier of the application, and determines whether the application is first determined according to the preset first access policy, the virtual machine identifier, and the application identifier.
  • the TrustZone authentication module determines whether the application can access the TrustZone based on the preset second access policy, virtual machine ID, and application identifier.
  • the request response module is sent to the TrustZone, and the Hypervisor and the verification module double-determine the access rights of different virtual machine identifiers and different application identifiers, thereby increasing the flexibility of access control.
  • the present application also provides an apparatus for access control. Since the principle of the access control device solves the problem is similar to the method of access control shown in FIG. 5 or FIG. 7 or FIG. 9, the access control is For the implementation of the device, reference may be made to the implementation of the method shown in FIG. 5 or FIG. 7 or FIG. 9, and the repeated description is omitted.
  • FIG. 10 where the device includes:
  • the receiving sub-module 1001 is configured to receive an access request sent by the application to access the TrustZone, where the access request includes a virtual machine identifier where the application is located, and an application identifier of the application;
  • the first determining sub-module 1002 is configured to determine, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone;
  • the sending submodule 1003 is configured to send the access request received by the receiving submodule 1001 to the request response module of the TrustZone.
  • the apparatus further includes:
  • the first feedback sub-module 1004 is configured to feed back to the application the first message that the TrustZone cannot be accessed when it is determined that the application cannot access the TrustZone.
  • the first determining submodule 1002 is located in the hypervisor, and is configured to determine, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone.
  • the access control apparatus shown in this embodiment of the present application may further include:
  • a first obtaining submodule where the first obtaining submodule is located in the hypervisor for acquiring user information
  • first verification sub-module located in the hypervisor, and is configured to pass the first verification of the user information acquired by the first acquisition sub-module;
  • the user information is information of a user who uses the application.
  • the access control apparatus shown in this embodiment of the present application may further include:
  • the second feedback sub-module is located in the hypervisor, and is configured to feed back to the application a second message that cannot access the TrustZone when the first verification fails.
  • the first obtaining submodule is configured to invoke the first user information collecting device to obtain user information.
  • the modules in the terminal where the first user information collection device is located are called.
  • the access request further includes user information
  • the first obtaining submodule is configured to obtain user information in the access request.
  • the first determining sub-module 1002 is located in the verification module of the TrustZone, and is configured to determine that the application can access the TrustZone according to the preset first access policy, the virtual machine identifier, and the application identifier.
  • the access control apparatus shown in this embodiment of the present application may further include:
  • a second acquisition submodule where the second acquisition submodule is located in the verification module, and is used to obtain user information
  • the second verification sub-module is located in the verification module, and is configured to pass the second verification of the user information acquired by the second acquisition sub-module.
  • the access control apparatus shown in this embodiment of the present application may further include:
  • the third feedback sub-module is located in the verification module, and is configured to feed back, to the application, a third message that cannot access the TrustZone when the second verification fails.
  • the second obtaining submodule is configured to invoke the second user information collecting device to obtain user information.
  • the second user information collection device is called by each module in the TrustZone.
  • the access request further includes user information
  • the second obtaining submodule is configured to obtain user information in the access request.
  • the first determining submodule 1002 is located in the hypervisor, and is configured to determine, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone.
  • the access control apparatus shown in this embodiment of the present application may further include:
  • the second determining sub-module is located in the verification module, and is configured to determine that the application can access the TrustZone according to the preset second access policy, the virtual machine identifier, and the application identifier.
  • the access control apparatus shown in this embodiment of the present application may further include:
  • a third obtaining submodule where the third obtaining submodule is located in the verification module, and is used for acquiring user information
  • the third verification sub-module is located in the verification module, and is configured to pass the third verification of the user information acquired by the third acquisition sub-module.
  • the access control apparatus shown in this embodiment of the present application may further include:
  • the fourth feedback sub-module is located in the verification module, and is configured to feed back, to the application, the fourth message that cannot access the TrustZone when the third verification fails.
  • the third obtaining submodule is configured to invoke the second user information collecting device to obtain user information.
  • the access request further includes user information
  • the third obtaining submodule is configured to obtain user information in the access request.
  • the access request includes the virtual machine identifier of the application, the application identifier of the application, and determining that the application can access the TrustZone according to the preset access policy, the virtual machine identifier, and the application identifier;
  • the request response module sent by the access request to the TrustZone implements flexible control over the access rights of different virtual machine identifiers and different application identifiers.
  • the present application also provides a system for access control. Since the principle of the access control system solves the problem is similar to the method of the access control shown in FIG. 5, the implementation of the access control system can be seen in the figure. The implementation of the method shown in FIG. 5 is not repeated here.
  • FIG. 12 includes: at least one virtual machine 1201, TrustZone 1202, and access control device 1203;
  • the access control device 1203 is configured to receive an access request; determine, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone 1202; and send the access request to the request response module of the TrustZone 1202;
  • the request response module of TrustZone 1202 is used to respond to access requests.
  • the access control device 1203 is further configured to: when determining that the application cannot access the TrustZone 1202, feed back to the application the first message that the TrustZone 1202 cannot be accessed.
  • the system further includes: Hypervisor 1204;
  • Access control device 1203 is located in Hypervisor 1204.
  • the access control device is located in the hypervisor and can receive an access request sent by the application to access the TrustZone.
  • the access request includes the virtual machine identifier of the application, the application identifier of the application, and the default access policy, the virtual machine identifier, and the application identifier.
  • the present application also provides a system for access control. Since the principle of the access control system solves the problem is similar to the method of the access control shown in FIG. 7, the implementation of the access control system can be seen in the figure. The implementation of the method shown in 7 will not be repeated here.
  • FIG. 14 includes: at least one virtual machine 1401, TrustZone 1402, and access control device 1403;
  • the application is run in the virtual machine 1401.
  • the access control device 1403 sends an access request to the TrustZone 1402, where the access request includes the virtual machine identifier where the application is located, and the application identifier of the application;
  • the access control device 1403 is configured to receive an access request; determine, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone 1402; and send the access request to the request response module of the TrustZone 1402;
  • the request response module of TrustZone 1402 is used to respond to access requests.
  • the access control device 1403 is further configured to: when determining that the application cannot access the TrustZone 1402, feed back to the application the first message that the TrustZone 1402 cannot be accessed.
  • the access control device 1403 is located in the TrustZone 1402.
  • the access control device is located in the TrustZone and can receive an access request sent by the application to access the TrustZone.
  • the access request includes the virtual machine identifier of the application, the application identifier of the application, and the default access policy, the virtual machine identifier, and the application identifier.
  • To determine that the application can access the TrustZone send the access request to the TrustZone request response module, which enables the authentication module to flexibly control the access rights of different virtual machine identifiers and different application identifiers.
  • the present application also provides a system for access control. Since the principle of the access control system solves the problem is similar to the method of the access control shown in FIG. 9, the implementation of the access control system can be seen in the figure. The implementation of the method shown in Figure 9 is not repeated here.
  • FIG. 15, includes: at least one virtual machine 1501, TrustZone 1502, and access control device 1503;
  • the application 1501 is run in the virtual machine, and when the application accesses the TrustZone 1502, the access control device 1503 sends an access request to access the TrustZone 1502, where the access request includes the virtual machine identifier where the application is located, and the application identifier of the application;
  • the access control device 1503 is configured to receive an access request, determine, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone 1502, and send the access request to the request response module of the TrustZone 1502.
  • the request response module of TrustZone 1502 is used to respond to access requests.
  • the access control device 1503 is further configured to: when determining that the application cannot access the TrustZone 1502, feed back to the application the first message that the TrustZone 1502 cannot be accessed.
  • Hypervisor 1504 the system further includes: Hypervisor 1504;
  • Access control device 1503 comprising a first access control sub-device 15031 and a second access control sub-device 15032;
  • the first access control sub-device 15031 is located in the Hypervisor 1504, and is configured to determine, according to the preset first access policy, the virtual machine identifier, and the application identifier, that the application can access the TrustZone 1502;
  • the second access control sub-device 15032 is located in the TrustZone 1502, and is configured to determine, according to the preset second access policy, the virtual machine identifier, and the application identifier, after the first access control sub-device 15031 determines that the application can access the TrustZone 1502. Ability to access TrustZone 1502; send an access request to the request response module of TrustZone 1502.
  • the access control device is located in the Hypervisor and the TrustZone, and can receive an access request sent by the application to access the TrustZone in the Hypervisor.
  • the access request includes the virtual machine identifier of the application, the application identifier of the application, and the first access policy according to the preset. , the virtual machine ID and the application ID, determine for the first time whether the application can access the TrustZone; when the hypervisor determines that the application can access the TrustZone, determine the application again in the TrustZone according to the preset second access policy, virtual machine ID and application identifier.
  • the authentication module determines that the application can access the TrustZone, it sends the access request to the TrustZone request response module, which implements the dual judgment of the Hypervisor and TrustZone for different virtual machine IDs and different application IDs. Access control flexibility.
  • embodiments of the present invention can be provided as a method, system, or computer program product. Accordingly, the present invention may employ an entirely hardware embodiment, an entirely software embodiment, Or in the form of an embodiment of the software and hardware aspects. Moreover, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
  • the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Storage Device Security (AREA)

Abstract

本发明提供了一种访问控制的方法、装置和系统，属于虚拟化技术领域。所述方法包括：接收应用程序发送的访问TrustZone的访问请求，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识；根据预设的访问策略、虚拟机标识和应用标识，确定应用程序能够访问TrustZone；将访问请求发送至TrustZone的请求响应模块。本发明接收应用程序发送的访问TrustZone的访问请求；根据预设的访问策略、虚拟机标识和应用标识，确定应用程序能够访问TrustZone；将访问请求发送至TrustZone的请求响应模块，实现了针对不同虚拟机标识和不同应用标识的访问权限进行灵活控制。

Description

访问控制的方法、装置和系统 技术领域
本发明涉及虚拟化技术领域，尤其涉及访问控制的方法、装置和系统。
背景技术
《中华人民共和国通信行业标准——移动终端可信环境技术要求(报批稿)》中规定，移动终端的可信环境是存在与移动终端内，通过混合使用硬件和软件的方法在SoC(System on Chip，系统级芯片)上隔离出两个平行的执行环境：普通的非保密执行环境和安全的保密环境。其中，称非保密执行环境为富执行环境REE(Rich Execution Environment)，它执行移动终端操作系统；安全的保密环境被称为可信执行环境TEE(Trusted Execution Environment)，它针对在REE环境中生成的软件攻击提供保护，其架构如图1所示。
其中，一种在SoC上运行TEE的平台的架构为TrustZone。TrustZone是ARM针对消费电子设备安全所提出的一种架构，是整个系统设计过程中的安全体系的扩展，目标是防范设备可能遭受到的多种特定威胁，包括来自恶意软件或设备的持有人的威胁。
在需要TrustZone提供保护的各场景中，访问控制是重要场景之一。
以图1所示架构中的支付应用需要访问TrustZone，并在TrustZone中运行以实现支付应用的支付功能为例，应用程序生成访问TrustZone的访问请求，访问请求中包括支付应用的标识；TrustZone获得访问请求后，其请求响应模块根据访问请求中支付应用的标识，对该访问请求进行响应，以在支付功能实现过程中提供保护。
随着虚拟化技术的发展，移动终端中虚拟化技术和可信环境技术进行了 融合，产生如图2所示的架构，其中，Hypervisor，也叫虚拟机监视器，是一种运行在物理服务器和操作系统之间的中间软件层，可允许多个虚拟机和应用共享一套基础物理硬件，它可以协调访问服务器上的所有物理设备和虚拟机，是所有虚拟化技术的核心。
对于图2所示的架构，任一虚拟机均能够以发送访问请求的方式访问TrustZone，实现功能，即每个虚拟机的访问TrustZone的权限均相同。然而，随着虚拟机的增多，不同虚拟机的需要不同的访问权限，以对虚拟机的访问进行灵活的控制。
发明内容
为解决对虚拟机的访问进行灵活控制的问题，本发明实施例提出了一种访问控制的方法、装置和系统。
第一方面，本发明实施例提供了一种访问控制的方法，所述方法包括：
接收应用程序发送的访问TrustZone的访问请求，所述访问请求包括所述应用程序所在的虚拟机标识，所述应用程序的应用标识；
根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用程序能够访问所述TrustZone；
将所述访问请求发送至所述TrustZone的请求响应模块。
可选地，若确定所述应用程序不能访问所述TrustZone，则向所述应用程序反馈不能访问所述TrustZone的第一消息。
可选地，所述根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用程序能够访问所述TrustZone，包括：
虚拟机监视器Hypervisor根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone。
可选地，在所述Hypervisor确定所述应用能够访问所述TrustZone之后，在将所述访问请求发送至所述TrustZone的请求响应模块之前，还包括：
所述Hypervisor获取用户信息，并对所述用户信息第一验证通过；
所述用户信息为使用所述应用程序的用户的信息。
可选地，当第一验证不通过时，所述Hypervisor向所述应用程序反馈不能访问所述TrustZone的第二消息。
可选地，所述Hypervisor获取用户信息，包括：
所述Hypervisor调用第一用户信息采集设备获取用户信息；
所述第一用户信息采集设备被所述方法所在终端中各模块调用。
可选地，所述访问请求还包括用户信息；
所述Hypervisor获取用户信息，包括：
所述Hypervisor获取所述访问请求中的用户信息。
可选地，所述根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用程序能够访问所述TrustZone，包括：
所述TrustZone的验证模块根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone。
可选地，在所述验证模块确定所述应用能够访问所述TrustZone之后，在将所述访问请求发送至所述TrustZone的请求响应模块之前，还包括：
所述验证模块获取用户信息，并对所述用户信息第二验证通过。
可选地，当第二验证不通过时，所述验证模块向所述应用程序反馈不能访问所述TrustZone的第三消息。
可选地，所述验证模块获取用户信息，包括：
所述验证模块调用第二用户信息采集设备获取用户信息；
所述第二用户信息采集设备被所述TrustZone中各模块调用。
可选地，所述访问请求还包括用户信息；
所述验证模块获取用户信息，包括：
所述验证模块获取所述访问请求中的用户信息。
可选地，所述根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用程序能够访问所述TrustZone，包括：
所述Hypervisor根据预设的第一访问策略、所述虚拟机标识和所述应用 标识，确定所述应用能够访问所述TrustZone。
可选地，在所述Hypervisor确定所述应用能够访问所述TrustZone之后，在将所述访问请求发送至所述TrustZone的请求响应模块之前，还包括：
所述验证模块根据预设的第二访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone。
可选地，在所述验证模块确定所述应用能够访问所述TrustZone之后，在将所述访问请求发送至所述TrustZone的请求响应模块之前，还包括：
所述验证模块获取用户信息，并对所述用户信息第三验证通过。
可选地，当第三验证不通过时，所述验证模块向所述应用程序反馈不能访问所述TrustZone的第四消息。
可选地，所述验证模块获取用户信息，包括：
所述验证模块调用所述第二用户信息采集设备获取用户信息。
可选地，所述访问请求还包括用户信息；
所述验证模块获取用户信息，包括：
所述验证模块获取所述访问请求中的用户信息。
第二方面，本发明实施例提供了一种访问控制的装置，所述装置包括：
接收子模块，用于接收应用程序发送的访问TrustZone的访问请求，所述访问请求包括所述应用程序所在的虚拟机标识，所述应用程序的应用标识；
第一确定子模块，用于根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用程序能够访问所述TrustZone；
发送子模块，用于将所述接收子模块接收的访问请求发送至所述TrustZone的请求响应模块。
可选地，所述装置还包括：
第一反馈子模块，用于当确定所述应用程序不能访问所述TrustZone时，向所述应用程序反馈不能访问所述TrustZone的第一消息。
可选地，所述第一确定子模块位于虚拟机监视器Hypervisor中，用于根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用能 够访问所述TrustZone。
可选地，所述装置，还包括：
第一获取子模块，所述第一获取子模块位于所述Hypervisor中，用于获取用户信息；
第一验证子模块，所述第一验证子模块位于所述Hypervisor中，用于对所述第一获取子模块获取的用户信息第一验证通过；
所述用户信息为使用所述应用程序的用户的信息。
可选地，所述装置，还包括：
第二反馈子模块，所述第二反馈子模块位于所述Hypervisor中，用于当第一验证不通过时，向所述应用程序反馈不能访问所述TrustZone的第二消息。
可选地，所述第一获取子模块，用于调用第一用户信息采集设备获取用户信息；
所述第一用户信息采集设备被所述方法所在终端中各模块调用。
可选地，所述访问请求还包括用户信息；
第一获取子模块，用于获取所述访问请求中的用户信息。
可选地，所述第一确定子模块位于所述TrustZone的验证模块中，用于根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone。
可选地，所述装置，还包括：
第二获取子模块，所述第二获取子模块位于所述验证模块中，用于获取用户信息；
第二验证子模块，所述第二验证子模块位于所述验证模块中，用于对所述第二获取子模块获取的用户信息第二验证通过。
可选地，所述装置，还包括：
第三反馈子模块，所述第三反馈子模块位于所述验证模块中，用于当第二验证不通过时，向所述应用程序反馈不能访问所述TrustZone的第三消息。
可选地，所述第二获取子模块，用于调用第二用户信息采集设备获取用 户信息；
所述第二用户信息采集设备被所述TrustZone中各模块调用。
可选地，所述访问请求还包括用户信息；
所述第二获取子模块，用于获取所述访问请求中的用户信息。
可选地，所述第一确定子模块位于所述Hypervisor中，用于根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone。
可选地，所述装置，还包括：
第二确定子模块，所述第二确定子模块位于所述验证模块中，用于根据预设的第二访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone。
可选地，所述装置，还包括：
第三获取子模块，所述第三获取子模块位于所述验证模块中，用于获取用户信息；
第三验证子模块，所述第三验证子模块位于所述验证模块中，用于对所述第三获取子模块获取的用户信息第三验证通过。
可选地，所述装置，还包括：
第四反馈子模块，所述第四反馈子模块位于所述验证模块中，用于当第三验证不通过时，向所述应用程序反馈不能访问所述TrustZone的第四消息。
可选地，所述第三获取子模块，用于调用所述第二用户信息采集设备获取用户信息。
可选地，所述访问请求还包括用户信息；
所述第三获取子模块，用于获取所述访问请求中的用户信息。
第三方面，本发明实施例提供了一种访问控制的系统，所述系统包括：至少一个虚拟机、TrustZone、访问控制的装置；
所述虚拟机中运行应用程序，当所述应用程序访问所述TrustZone时，向所述访问控制的装置发送访问TrustZone的访问请求，所述访问请求包括所述 应用程序所在的虚拟机标识，所述应用程序的应用标识；
所述访问控制的装置，用于接收所述访问请求；根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用程序能够访问所述TrustZone；将所述访问请求发送至所述TrustZone的请求响应模块；
所述TrustZone的请求响应模块用于响应所述访问请求。
可选地，所述访问控制的装置，还用于当确定所述应用程序不能访问所述TrustZone时，向所述应用程序反馈不能访问所述TrustZone的第一消息。
可选地，所述系统，还包括：虚拟机监视器Hypervisor；
所述访问控制的装置，位于所述Hypervisor中。
可选地，所述访问控制的装置，位于所述TrustZone中。
可选地，所述系统，还包括：Hypervisor；
所述访问控制的装置，包括第一访问控制子装置和第二访问控制子装置；
所述第一访问控制子装置，位于Hypervisor中，用于根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone；
所述第二访问控制子装置，位于所述TrustZone中，用于在所述第一访问控制子装置确定所述应用程序能够访问所述TrustZone之后，根据预设的第二访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone；将所述访问请求发送至所述TrustZone的请求响应模块。
有益效果如下：
接收应用程序发送的访问TrustZone的访问请求，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识；根据预设的访问策略、虚拟机标识和应用标识，确定应用程序能够访问TrustZone；将访问请求发送至TrustZone的请求响应模块，实现了针对不同虚拟机标识和不同应用标识的访问权限进行灵活控制。
附图说明
下面将参照附图描述本发明的具体实施例，其中：
图1示出了本发明提供的一种系统架构示意图；
图2示出了本发明提供的另一种系统架构示意图；
图3示出了本发明提供的另一种系统架构示意图；
图4示出了本发明实施例一中提供的一种系统架构示意图；
图5示出了本发明实施例一中提供的一种访问控制的方法流程示意图；
图6示出了本发明实施例二中提供的一种系统架构示意图；
图7示出了本发明实施例二中提供的一种访问控制的方法流程示意图；
图8示出了本发明实施例三中提供的一种访问控制的方法流程示意图；
图9示出了本发明实施例三中提供的一种访问控制的方法流程示意图；
图10示出了本发明实施例四中提供的一种访问控制的装置的结构示意图；
图11示出了本发明实施例四中提供的另一种访问控制的装置的结构示意图；
图12示出了本发明实施例五中提供的一种访问控制的系统的结构示意图；
图13示出了本发明实施例五中提供的另一种访问控制的系统的结构示意图；
图14示出了本发明实施例六中提供的一种访问控制的系统的结构示意图；
图15示出了本发明实施例七中提供的一种访问控制的系统的结构示意图；
图16示出了本发明实施例七中提供的另一种访问控制的系统的结构示意图。
具体实施方式
为了使本发明的技术方案及优点更加清楚明白，以下结合附图对本发明 的示例性实施例进行进一步详细的说明，显然，所描述的实施例仅是本发明的一部分实施例，而不是所有实施例的穷举。并且在不冲突的情况下，本说明中的实施例及实施例中的特征可以互相结合。
采用现有技术中的方案，存在不能对虚拟机的访问进行有效控制的技术问题，本发明提供了解决方案，该解决方案可以于智能终端中，该智能终端可以为智能手机、智能机器人、平板电脑等设备，本发明并不对智能终端的具体产品进行限定，只要其包括至少一个虚拟机、TrustZone，并且可以通过网络通信即可。
本发明提供的解决方案核心在于，提出了一种包括至少一个虚拟机301、访问控制的装置302、TrustZone 303的架构，如图3所示。在该架构中，访问控制的装置可以实现针对不同虚拟机标识和不同应用标识的访问权的行灵活控制。
图3中，虚拟机301中运行应用程序，当用户希望虚拟机301中的应用程序访问TrustZone 303时，应用程序向访问控制的装置302发送访问TrustZone 303的访问请求，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识；
访问控制的装置302，用于接收访问请求，根据预设的第一访问策略，以及访问请求中虚拟机标识和应用标识，确定应用程序能够访问TrustZone 303后，将访问请求发送至TrustZone 303的请求响应模块，从而实现根据虚拟机标识和应用标识对不同虚拟机301中的不同应用程序的访问权限进行灵活控制的技术效果；
TrustZone 303位于CPU(Central Processing Unit，中央处理器)中，TrustZone 303的请求响应模块接收到访问请求后，响应该访问请求。
图3所示的架构中的访问控制的装置302，在实际应用时，存在多种具体的实现方式。下面分别以访问控制的装置302在Hypervisor中实现，访问控制的装置302在TrustZone 303中实现，访问控制的装置302同时在Hypervisor和TrustZone 303中实现为例进行说明。
实施例一
针对图3所示的架构中的访问控制的装置302在Hypervisor中实现的具体方式，本申请提供了一种访问控制的方法。访问控制的装置302位于Hypervisor中的具体实现架构如图4所示，包括：
1)2个VM(Virtual Machine，虚拟机)。分别为个人VM和企业VM，其中，个人VM中运行支付应用3，企业VM中运行支付应用1和即时聊天应用2；
2)Hypervisor。Hypervisor上运行有访问控制的装置，该访问控制的装置执行本实施例提供的访问控制的方法，且Hypervisor上存储有第一访问策略，通过第一访问策略可以对VM中应用发送的访问TrustZone的访问请求进行访问策略判断，从而实现根据不同VM和不同应用程序的访问权限进行灵活控制的技术效果；
3)CPU。CPU上包括TrustZone，TrustZone中包括请求响应模块，可以在接收到VM中应用程序发送的访问请求后，响应该访问请求。除此之外，TrustZone中运行有TrustZone操作系统，TrustZone操作系统包括用于身份认证的认证模块，用于通信的通信模块等其他模板，本实施例不对TrustZone中包括的具体模块进行限定。
需要说明的是：
(1)Hypervisor上运行有访问控制的装置，且Hypervisor上存储有第一访问策略。第一访问策略可以存储在访问控制的装置中，也可以存储在访问控制的装置外，图4仅以第一访问策略存储在访问控制的装置中为例进行展示，本实施例不对实际应用时第一访问策略的具体存储位置进行限定。
(2)请求响应模块的名称仅为示意，在具体实施时，还可以称为其他名称，不论叫何名称，只要实现响应访问请求功能的模块，均可认为是本实施例的请求响应模块。若在实际应用中，多个模块共同实现响应访问请求功能，则多个模块均可认为是本实施例的请求响应模块的子模块。
(3)CPU上还可以连接有第一用户信息采集设备，该第一用户信息采集设备可以被图4所示的架构中的各模块调用。其中，第一用户信息采集设备包括但不限于：硬键盘、虹膜扫描器、刷卡器、存有用户指纹信息的U盾、指纹扫描器等。且，上述“第一”仅为编号，用于对不同设备连接的用户信息采集设备进行区分，无实际意义。
基于图4的架构，本实施例以3个例子进行具体说明，其中：
例子1：支付应用1发起访问请求1，以在TrustZone中实现付款功能1，其中，支付应用1采用指纹方式验证用户身份，且企业VM的虚拟机标识为OS1，支付应用1的应用标识为ID1。
例子2：即时聊天应用2发起访问请求2，以在TrustZone中实现付款功能2，其中，企业VM的虚拟机标识为OS1，即时聊天应用2的应用标识为ID2。
例子3：支付应用3发起访问请求3，以在TrustZone中实现付款功能3，其中，个人VM的虚拟机标识为OS2，支付应用3的应用标识为ID3。
其中，支付应用1和支付应用3可以是相同的应用，也可以是不同的应用，本实施例不对支付应用1和支付应用3之间的关系进行限定。
若支付应用1和支付应用3为相同的应用，则付款功能1和付款功能3可以是相同的功能，也可以是不同的功能。本实施例不对支付应用1和支付应用3之间的关系进行限定。
另外，若支付应用1和支付应用3为相同的应用，ID1与ID3可以相同，也可以不同。本实施例不对ID1与ID3之间的关系进行限定。
参见图5，本实施例提供的方法流程具体如下：
501：Hypervisor接收应用程序发送的访问TrustZone的访问请求；
其中，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识。
访问请求除包括上述信息之外，还可以根据应用程序的具体需要包括其他信息，例如支付金额、支付对象、支付说明、备注等。
由于Hypervisor上运行本实施例提供的方法，因此，本步骤的执行主体 可以为Hypervisor。
例子1：Hypervisor获取支付应用1发送的访问请求1，访问请求1包括OS1，ID1。
例子2：Hypervisor获取即时聊天应用2发送的访问请求2，访问请求2包括OS1，ID2。
例子3：Hypervisor获取支付应用3发送的访问请求3，访问请求3包括OS3，ID3。
502：Hypervisor根据预设的第一访问策略、虚拟机标识和应用标识，确定应用程序是否能够访问TrustZone，若能够访问TrustZone，则执行步骤503，若不能访问TrustZone，则执行步骤504；
其中，第一访问策略可以自动从网络中获取，也可以通过人机接口获取，还可以通过其他方式获取，本实施例不对第一访问策略的获取方式进行限定。
由于第一访问策略可以更改，因此，若有多份第一访问策略，可以选择获取时间最近的一份访问策略，也可以根据预设规则选择指定的第一访问策略。
若预设的第一访问策略为：
策略1：企业VM(OS1)的支付应用1(ID1)有访问TrustZone的权限；
策略2：企业VM(OS1)的即时聊天应用2(ID2)没有访问TrustZone的权限；
策略3：个人VM(OS2)的任何应用程序均没有访问TrustZone的权限。
则，例子1：Hypervisor根据策略1，可以确定支付应用1能够访问TrustZone。
例子2：Hypervisor根据策略2，可以确定即时聊天应用2不能够访问TrustZone。
例子3：Hypervisor根据策略3，可以确定支付应用3不能够访问TrustZone。
503：Hypervisor将访问请求发送至TrustZone的请求响应模块；
例子1，Hypervisor将访问请求1发送至TrustZone的请求响应模块。
504：Hypervisor向应用程序反馈不能访问TrustZone的第一消息。
其中，第一消息用于描述应用程序不能访问TrustZone，其内容可以包括：不能访问的具体原因，如虚拟机没有访问TrustZone的权限，或者，虚拟机的某应用程序没有访问TrustZone的权限。
例子2：Hypervisor向应用程序反馈不能访问TrustZone的第一消息，第一消息描述企业VM中即时聊天应用2没有访问TrustZone的权限。
例子3：Hypervisor向应用程序反馈不能访问TrustZone的第一消息，第一消息描述个人VM没有访问TrustZone的权限。
另外，在实际应用中，往往会对用户身份进行验证，以防止非法用户盗用身份使用应用。因此，为了提升本实施例提供的方法的安全性，Hypervisor在执行步骤502，且确定应用程序能够访问TrustZone之后，执行步骤503将访问请求发送至TrustZone的请求响应模块之前，还可以执行如下步骤：
步骤1.1：Hypervisor获取用户信息；
其中，用户信息为使用应用程序的用户的信息；
具体的，Hypervisor可以通过如下2种方式中的一种获取用户信息：
1)当执行本实施例提供的方法的终端连接有第一用户信息采集设备，且第一用户信息采集设备可以被该终端中各模块调用时，Hypervisor调用第一用户信息采集设备获取用户信息；
2)当访问请求还包括用户信息时，Hypervisor获取访问请求中的用户信息。
例子1，Hypervisor调用第一用户信息采集设备(例如：存有用户指纹信息的U盾、指纹扫描器等)获取用户指纹信息；或者，当访问请求还包括用户信息时(例如：用户指纹信息)，Hypervisor获取访问请求中的用户指纹信息。
步骤1.2：Hypervisor对用户信息进行第一验证，若第一验证通过，则执行步骤503，若第一验证不通过，则执行步骤1.3；
可按现有用户信息的验证方法，对用户信息进行验证。例如，将步骤1.1 中获取到的用户指纹信息与预设的该用户的标准指纹信息进行匹配，若匹配成功，则第一验证通过，若匹配不成功，则第一验证不通过。
步骤1.3：Hypervisor向应用程序反馈不能访问TrustZone的第二消息。
其中，第二消息用于描述应用程序不能访问TrustZone，其内容可以包括：不能访问的具体原因，如身份验证没通过。
需要说明的是，本实施例及后续实施例涉及的“第一”、“第二”等来描述消息、信息采集设备、验证、和访问策略等，但“第一”、“第二”等仅用来将消息、信息采集设备、验证、和访问策略等彼此区分开，无其他实质含义。即第一消息与第二消息可以相同也可以不同，第一访问策略与第二访问策略可以相同也可以不同。
有益效果：
Hypervisor接收应用程序发送的访问TrustZone的访问请求，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识；根据预设的访问策略、虚拟机标识和应用标识，确定应用程序能够访问TrustZone；将访问请求发送至TrustZone的请求响应模块，实现了Hypervisor针对不同虚拟机标识和不同应用标识的访问权限进行灵活控制。
实施例二
针对图3所示的架构中的访问控制的装置302在TrustZone中实现的具体方式，本申请提供了一种访问控制的方法。访问控制的装置302位于TrustZone中的具体实现架构如图6所示，包括：
1)2个VM(Virtual Machine，虚拟机)。分别为个人VM和企业VM，其中，个人VM中运行支付应用3，企业VM中运行支付应用1和即时聊天应用2；
2)Hypervisor。Hypervisor用于接收到应用程序发送的访问TrustZone的访问请求后，将该访问请求转发至访问控制的装置。
3)CPU。CPU上包括TrustZone，TrustZone中包括验证模块和请求响应 模块，同时，TrustZone上存储有第一访问策略。
其中，验证模块上运行有访问控制的装置，该访问控制的装置执行本实施例提供的访问控制的方法，且验证模块可以获取TrustZone存储的第一访问策略，通过第一访问策略可以对访问请求进行访问策略判断，从而实现根据不同VM和不同应用程序的访问权限进行灵活控制的技术效果；
请求响应模块，可以在接收到VM中应用程序发送的访问请求后，响应该访问请求。
除此之外，TrustZone中运行有TrustZone操作系统，TrustZone操作系统包括用于身份认证的认证模块，用于通信的通信模块等其他模板。
另外，TrustZone上还可以连接有第二用户信息采集设备，该第二用户信息采集设备仅可以被图6所示的架构中TrustZone的各模块调用，不可以被图6所示的架构中的其他模块调用。其中，第二用户信息采集设备包括但不限于：硬键盘、虹膜扫描器、刷卡器、存有用户指纹信息的U盾、指纹扫描器等。
此外，TrustZone上运行有访问控制的装置，且TrustZone上存储有第一访问策略。第一访问策略可以存储在访问控制的装置中，也可以存储在访问控制的装置外，图6仅以第一访问策略存储在访问控制的装置外为例进行展示，本实施例不对实际应用时第一访问策略的具体存储位置进行限定。
基于图6的架构，本实施例仍以图5所示实施例中涉及的3个例子为例，进行具体说明。
参见图7，本实施例提供的方法流程具体如下：
701：Hypervisor接收应用程序发送的访问TrustZone的访问请求，将访问请求转发至TrustZone的验证模块；
其中，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识。
访问请求除包括上述信息之外，还可以根据应用程序的具体需要包括其他信息，例如支付金额、支付对象、支付说明、备注等。
702：TrustZone的验证模块接收访问请求，根据预设的第一访问策略、虚 拟机标识和应用标识，确定应用程序是否能够访问TrustZone，若能够访问TrustZone，则执行步骤703，若不能访问TrustZone，则执行步骤704；
若预设的第一访问策略为：
策略1：企业VM(OS1)的支付应用1(ID1)有访问TrustZone的权限；
策略2：企业VM(OS1)的即时聊天应用2(ID2)没有访问TrustZone的权限；
策略3：个人VM(OS2)的任何应用程序均没有访问TrustZone的权限。
则，例子1：验证模块根据策略1，可以确定支付应用1能够访问TrustZone。
例子2：验证模块根据策略2，可以确定即时聊天应用2不能够访问TrustZone。
例子3：验证模块根据策略3，可以确定支付应用3不能够访问TrustZone。
703：验证模块将访问请求发送至TrustZone的请求响应模块；
例子1，验证模块将访问请求1发送至TrustZone的请求响应模块。
704：验证模块向应用程序反馈不能访问TrustZone的第一消息。
验证模块可以先向Hypervisor反馈不能访问TrustZone的第一消息，Hypervisor接收到第一消息后，将第一消息转发至应用程序。
另外，在实际应用中，往往会对用户身份进行验证，以防止非法用户盗用身份使用应用。因此，为了提升本实施例提供的方法的安全性，验证模块在执行步骤702，且确定应用程序能够访问TrustZone之后，执行步骤703将访问请求发送至TrustZone的请求响应模块之前，还可以执行如下步骤：
步骤2.1：验证模块获取用户信息；
具体的，验证模块可以通过如下3种方式中的一种获取用户信息：
1)当执行本实施例提供的方法的终端连接有第一用户信息采集设备，且第一用户信息采集设备可以被该终端中各模块调用时，验证模块调用第一用户信息采集设备获取用户信息；
对于此种方式，由于第一用户信息采集设备与终端连接，且第一用户信息采集设备可以被该终端中各模块调用，若终端中某模块不安全，则可能出 现通过第一用户信息采集设备采集到的用户信息在验证模块获取到之前，被该不安全模块篡改的情况，降低了验证模块获取到的用户信息的准确性。
2)当执行本实施例提供的方法的终端的TrustZone上连接有第二用户信息采集设备，且第二用户信息采集设备可以被该TrustZone中各模块调用时，验证模块调用第二用户信息采集设备获取用户信息；
对于此种方式，由于第二用户信息采集设备直接与TrustZone连接，且第二用户信息采集设备仅可以被TrustZone中的各模块调用，可以防止用户信息在验证模块获取到之前被篡改的情况发生，提升了验证模块获取到的用户信息的准确性。
3)当访问请求还包括用户信息时，验证模块获取访问请求中的用户信息。
例子1，验证模块调用第二用户信息采集设备(例如：存有用户指纹信息的U盾、指纹扫描器等)获取用户指纹信息。
步骤2.2：验证模块对用户信息进行第二验证，若第二验证通过，则执行步骤703，若第二验证不通过，则执行步骤2.3；
步骤2.3：验证模块向应用程序反馈不能访问TrustZone的第三消息。
其中，第三消息用于描述应用程序不能访问TrustZone，其内容可以包括：不能访问的具体原因，如身份验证没通过。
验证模块可以先向Hypervisor反馈不能访问TrustZone的第三消息，Hypervisor接收到第三消息后，将第三消息转发至应用程序。
有益效果：
TrustZone的验证模块接收应用程序发送的访问TrustZone的访问请求，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识；根据预设的访问策略、虚拟机标识和应用标识，确定应用程序能够访问TrustZone；将访问请求发送至TrustZone的请求响应模块，实现了验证模块针对不同虚拟机标识和不同应用标识的访问权限进行灵活控制。
实施例三
针对图3所示的架构中的访问控制的装置302在同时在Hypervisor和TrustZone 303中实现的具体方式，本申请提供了一种访问控制的方法。在此种实现方式中，访问控制的装置302包括：第一访问控制子装置和第二访问控制子装置，第一访问控制子装置位于Hypervisor中，第二访问控制子装置位于TrustZone 303中，由Hypervisor和TrustZone执行双重访问策略判断，从而实现根据不同VM和不同应用程序的访问权限进行灵活控制的技术效果。
具体参见图8，该架构包括：
1)2个VM(Virtual Machine，虚拟机)。分别为个人VM和企业VM，其中，个人VM中运行支付应用3，企业VM中运行支付应用1和即时聊天应用2；
2)Hypervisor。Hypervisor上存储有第一访问策略，且Hypervisor上运行有第一访问控制子装置，该第一访问控制子装置通过第一访问策略可以对VM中应用发送的访问TrustZone的访问请求进行访问策略判断，从而进行首次访问控制；
3)CPU。CPU上包括TrustZone，TrustZone中包括验证模块和请求响应模块，同时，TrustZone上存储有第二访问策略。除此之外，TrustZone中运行有TrustZone操作系统，TrustZone操作系统包括用于身份认证的认证模块，用于通信的通信模块等其他模板。
验证模块上运行有第二访问控制子装置，该第二访问控制子装置通过第二访问策略可以对VM中应用发送的访问TrustZone的访问请求进行访问策略判断，从而进行再次访问控制。
另外，CPU上还可以连接有第一用户信息采集设备，TrustZone上还可以连接有第二用户信息采集设备。
此外，Hypervisor上运行有第一访问控制子装置，且Hypervisor上存储有第一访问策略。第一访问策略可以存储在第一访问控制子装置中，也可以存储在第一访问控制子装置外，图8仅以第一访问策略存储在第一访问控制子装置中为例进行展示，本实施例不对实际应用时第一访问策略的具体存储位 置进行限定。
TrustZone上运行有第二访问控制子装置，且TrustZone上存储有第二访问策略。第二访问策略可以存储在第二访问控制子装置中，也可以存储在第二访问控制子装置外，图8仅以第二访问策略存储在第二访问控制子装置外为例进行展示，本实施例不对实际应用时第二访问策略的具体存储位置进行限定。
基于图8的架构，本实施例仍以图5所示实施例中涉及的3个例子为例，进行具体说明。
参见图9，本实施例提供的方法流程具体如下：
901：Hypervisor接收应用程序发送的访问TrustZone的访问请求；
其中，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识；
此步骤的具体实现方式与步骤501相同，详见步骤501，此处不再赘述。
902：Hypervisor根据预设的第一访问策略、虚拟机标识和应用标识，确定应用程序是否能够访问TrustZone，若能够访问TrustZone，则执行步骤904至步骤907，若不能访问TrustZone，则执行步骤903；
此步骤的具体实现方式与步骤502相同，详见步骤502，此处不再赘述。
903：Hypervisor向应用程序反馈不能访问TrustZone的第一消息。
此步骤的具体实现方式与步骤504相同，详见步骤504，此处不再赘述。
904：Hypervisor将访问请求转发至TrustZone的验证模块；
905：验证模块根据预设的第二访问策略、虚拟机标识和应用标识，确定应用程序是否能够访问TrustZone，若能够访问TrustZone，则执行步骤906，若不能访问TrustZone，则执行步骤907；
其中，第二访问策略可以与步骤902中的第一访问策略相同，也可以不同。
若预设的第二访问策略为：
策略4：企业VM(OS1)的支付应用1(ID1)有访问TrustZone的权限；
策略5：企业VM(OS1)的即时聊天应用2(ID2)没有访问TrustZone 的权限；
策略6：个人VM(OS2)的任何应用程序均没有访问TrustZone的权限。
则，例子1：验证模块根据策略4，可以确定支付应用1能够访问TrustZone。
例子2：验证模块根据策略5，可以确定即时聊天应用2不能够访问TrustZone。
例子3：验证模块根据策略6，可以确定支付应用3不能够访问TrustZone。
906：验证模块将访问请求发送至TrustZone的请求响应模块；
此步骤的具体实现方式与步骤703相同，详见步骤703，此处不再赘述。
907：验证模块向应用程序反馈不能访问TrustZone的第一消息。
此步骤的具体实现方式与步骤704相同，详见步骤704，此处不再赘述。
另外，在实际应用中，往往会对用户身份进行验证，以防止非法用户盗用身份使用应用。因此，为了提升本实施例提供的方法的安全性，验证模块在执行步骤905，且确定应用程序能够访问TrustZone之后，执行步骤906将访问请求发送至TrustZone的请求响应模块之前，还可以执行如下步骤：
步骤3.1：验证模块获取用户信息；
此步骤的具体实现方式与步骤2.1相同，详见步骤2.1，此处不再赘述。
步骤3.2：验证模块对用户信息进行第三验证，若第三验证通过，则执行步骤906，若第三验证不通过，则执行步骤3.3；
步骤3.3：验证模块向应用程序反馈不能访问TrustZone的第四消息。
其中，第四消息用于描述应用程序不能访问TrustZone，其内容可以包括：不能访问的具体原因，如身份验证没通过。
验证模块可以先向Hypervisor反馈不能访问TrustZone的第四消息，Hypervisor接收到第四消息后，将第四消息转发至应用程序。
有益效果：
Hypervisor接收应用程序发送的访问TrustZone的访问请求，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识；根据预设的第一访问策略、虚拟机标识和应用标识，首次确定应用程序是否能够访问TrustZone； 当Hypervisor确定应用程序能够访问TrustZone后，由TrustZone的验证模块根据预设的第二访问策略、虚拟机标识和应用标识，再次确定应用程序是否能够访问TrustZone；当验证模块确定应用程序能够访问TrustZone后，将访问请求发送至TrustZone的请求响应模块，实现了Hypervisor和验证模块针对不同虚拟机标识和不同应用标识的访问权限进行双重判断，增加了访问控制的灵活性。
实施例四
基于同一发明构思，本申请还提供了一种访问控制的装置，由于访问控制的装置解决问题的原理与图5或图7或图9所示的一种访问控制的方法相似，因此访问控制的装置的实施可以参见图5或图7或图9所示的方法的实施，重复之处不再赘述。
本申请实施例所示的访问控制装置的结构可以参见图10，所述装置包括：
接收子模块1001，用于接收应用程序发送的访问TrustZone的访问请求，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识；
第一确定子模块1002，用于根据预设的第一访问策略、虚拟机标识和应用标识，确定应用程序能够访问TrustZone；
发送子模块1003，用于将接收子模块1001接收的访问请求发送至TrustZone的请求响应模块。
参见图11，该装置还包括：
第一反馈子模块1004，用于当确定应用程序不能访问TrustZone时，向应用程序反馈不能访问TrustZone的第一消息。
可选地，第一确定子模块1002位于Hypervisor中，用于根据预设的第一访问策略、虚拟机标识和应用标识，确定应用能够访问TrustZone。
可选地，本申请实施例所示的访问控制装置，还可以包括：
第一获取子模块，第一获取子模块位于Hypervisor中，用于获取用户信息；
第一验证子模块，第一验证子模块位于Hypervisor中，用于对第一获取子模块获取的用户信息第一验证通过；
其中，用户信息为使用应用程序的用户的信息。
可选地，本申请实施例所示的访问控制装置，还可以包括：
第二反馈子模块，第二反馈子模块位于Hypervisor中，用于当第一验证不通过时，向应用程序反馈不能访问TrustZone的第二消息。
可选地，第一获取子模块，用于调用第一用户信息采集设备获取用户信息；
其中，第一用户信息采集设备所在终端中各模块调用。
可选地，访问请求还包括用户信息；
第一获取子模块，用于获取访问请求中的用户信息。
可选地，第一确定子模块1002位于TrustZone的验证模块中，用于根据预设的第一访问策略、虚拟机标识和应用标识，确定应用能够访问TrustZone。
可选地，本申请实施例所示的访问控制装置，还可以包括：
第二获取子模块，第二获取子模块位于验证模块中，用于获取用户信息；
第二验证子模块，第二验证子模块位于验证模块中，用于对第二获取子模块获取的用户信息第二验证通过。
可选地，本申请实施例所示的访问控制装置，还可以包括：
第三反馈子模块，第三反馈子模块位于验证模块中，用于当第二验证不通过时，向应用程序反馈不能访问TrustZone的第三消息。
可选地，第二获取子模块，用于调用第二用户信息采集设备获取用户信息；
其中，第二用户信息采集设备被TrustZone中各模块调用。
可选地，访问请求还包括用户信息；
第二获取子模块，用于获取访问请求中的用户信息。
可选地，第一确定子模块1002位于Hypervisor中，用于根据预设的第一访问策略、虚拟机标识和应用标识，确定应用能够访问TrustZone。
可选地，本申请实施例所示的访问控制装置，还可以包括：
第二确定子模块，第二确定子模块位于验证模块中，用于根据预设的第二访问策略、虚拟机标识和应用标识，确定应用能够访问TrustZone。
可选地，本申请实施例所示的访问控制装置，还可以包括：
第三获取子模块，第三获取子模块位于验证模块中，用于获取用户信息；
第三验证子模块，第三验证子模块位于验证模块中，用于对第三获取子模块获取的用户信息第三验证通过。
可选地，本申请实施例所示的访问控制装置，还可以包括：
第四反馈子模块，第四反馈子模块位于验证模块中，用于当第三验证不通过时，向应用程序反馈不能访问TrustZone的第四消息。
可选地，第三获取子模块，用于调用第二用户信息采集设备获取用户信息。
可选地，访问请求还包括用户信息；
第三获取子模块，用于获取访问请求中的用户信息。
有益效果如下：
接收应用程序发送的访问TrustZone的访问请求，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识；根据预设的访问策略、虚拟机标识和应用标识，确定应用程序能够访问TrustZone；将访问请求发送至TrustZone的请求响应模块，实现了针对不同虚拟机标识和不同应用标识的访问权限进行灵活控制。
实施例五
基于同一发明构思，本申请还提供了一种访问控制的系统，由于访问控制的系统解决问题的原理与图5所示的一种访问控制的方法相似，因此访问控制的系统的实施可以参见图5所示的方法的实施，重复之处不再赘述。
本申请实施例所示的访问控制系统的结构可以参见图12，该系统包括：至少一个虚拟机1201、TrustZone 1202、访问控制的装置1203；
虚拟机1201中运行应用程序，当应用程序访问TrustZone 1202时，向访问控制的装置1203发送访问TrustZone 1202的访问请求，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识；
访问控制的装置1203，用于接收访问请求；根据预设的第一访问策略、虚拟机标识和应用标识，确定应用程序能够访问TrustZone 1202；将访问请求发送至TrustZone 1202的请求响应模块；
TrustZone 1202的请求响应模块用于响应访问请求。
其中，访问控制的装置1203，还用于当确定应用程序不能访问TrustZone 1202时，向应用程序反馈不能访问TrustZone 1202的第一消息。
参见图13，该系统，还包括：Hypervisor 1204；
访问控制的装置1203，位于Hypervisor 1204中。
有益效果如下：
访问控制的装置位于Hypervisor中，可以接收应用程序发送的访问TrustZone的访问请求，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识；根据预设的访问策略、虚拟机标识和应用标识，确定应用程序能够访问TrustZone；将访问请求发送至TrustZone的请求响应模块，实现了Hypervisor针对不同虚拟机标识和不同应用标识的访问权限进行灵活控制。
实施例六
基于同一发明构思，本申请还提供了一种访问控制的系统，由于访问控制的系统解决问题的原理与图7所示的一种访问控制的方法相似，因此访问控制的系统的实施可以参见图7所示的方法的实施，重复之处不再赘述。
本申请实施例所示的访问控制系统的结构可以参见图14，该系统包括：至少一个虚拟机1401、TrustZone 1402、访问控制的装置1403；
虚拟机1401中运行应用程序，当应用程序访问TrustZone 1402时，向访问控制的装置1403发送访问TrustZone 1402的访问请求，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识；
访问控制的装置1403，用于接收访问请求；根据预设的第一访问策略、虚拟机标识和应用标识，确定应用程序能够访问TrustZone 1402；将访问请求发送至TrustZone 1402的请求响应模块；
TrustZone 1402的请求响应模块用于响应访问请求。
其中，访问控制的装置1403，还用于当确定应用程序不能访问TrustZone 1402时，向应用程序反馈不能访问TrustZone 1402的第一消息。
其中，访问控制的装置1403，位于TrustZone 1402中。
有益效果如下：
访问控制的装置位于TrustZone中，可以接收应用程序发送的访问TrustZone的访问请求，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识；根据预设的访问策略、虚拟机标识和应用标识，确定应用程序能够访问TrustZone；将访问请求发送至TrustZone的请求响应模块，实现了验证模块针对不同虚拟机标识和不同应用标识的访问权限进行灵活控制。
实施例七
基于同一发明构思，本申请还提供了一种访问控制的系统，由于访问控制的系统解决问题的原理与图9所示的一种访问控制的方法相似，因此访问控制的系统的实施可以参见图9所示的方法的实施，重复之处不再赘述。
本申请实施例所示的访问控制系统的结构可以参见图15，该系统包括：至少一个虚拟机1501、TrustZone 1502、访问控制的装置1503；
虚拟机中运行应用程序1501，当应用程序访问TrustZone 1502时，向访问控制的装置1503发送访问TrustZone 1502的访问请求，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识；
访问控制的装置1503，用于接收访问请求；根据预设的第一访问策略、虚拟机标识和应用标识，确定应用程序能够访问TrustZone 1502；将访问请求发送至TrustZone 1502的请求响应模块；
TrustZone 1502的请求响应模块用于响应访问请求。
其中，访问控制的装置1503，还用于当确定应用程序不能访问TrustZone 1502时，向应用程序反馈不能访问TrustZone 1502的第一消息。
参见图16，该系统，还包括：Hypervisor 1504；
访问控制的装置1503，包括第一访问控制子装置15031和第二访问控制子装置15032；
第一访问控制子装置15031，位于Hypervisor 1504中，用于根据预设的第一访问策略、虚拟机标识和应用标识，确定应用能够访问TrustZone 1502；
第二访问控制子装置15032，位于TrustZone 1502中，用于在第一访问控制子装置15031确定应用程序能够访问TrustZone 1502之后，根据预设的第二访问策略、虚拟机标识和应用标识，确定应用能够访问TrustZone 1502；将访问请求发送至TrustZone 1502的请求响应模块。
有益效果如下：
访问控制的装置位于Hypervisor和TrustZone中，可以在Hypervisor中接收应用程序发送的访问TrustZone的访问请求，访问请求包括应用程序所在的虚拟机标识，应用程序的应用标识；根据预设的第一访问策略、虚拟机标识和应用标识，首次确定应用程序是否能够访问TrustZone；当Hypervisor确定应用程序能够访问TrustZone后，在TrustZone中根据预设的第二访问策略、虚拟机标识和应用标识，再次确定应用程序是否能够访问TrustZone；当验证模块确定应用程序能够访问TrustZone后，将访问请求发送至TrustZone的请求响应模块，实现了Hypervisor和TrustZone针对不同虚拟机标识和不同应用标识的访问权限进行双重判断，增加了访问控制的灵活性。
为了描述的方便，以上所述装置的各部分以功能分为各种模块或单元分别描述。当然，在实施本发明时可以把各模块或单元的功能在同一个或多个软件或硬件中实现。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、 或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

Claims (41)

  1. 一种访问控制的方法，其特征在于，所述方法包括：
    接收应用程序发送的访问TrustZone的访问请求，所述访问请求包括所述应用程序所在的虚拟机标识，所述应用程序的应用标识；
    根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用程序能够访问所述TrustZone；
    将所述访问请求发送至所述TrustZone的请求响应模块。
  2. 根据权利要求1所述的方法，其特征在于，若确定所述应用程序不能访问所述TrustZone，则向所述应用程序反馈不能访问所述TrustZone的第一消息。
  3. 根据权利要求2所述的方法，其特征在于，所述根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用程序能够访问所述TrustZone，包括：
    虚拟机监视器Hypervisor根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone。
  4. 根据权利要求3所述的方法，其特征在于，在所述Hypervisor确定所述应用能够访问所述TrustZone之后，在将所述访问请求发送至所述TrustZone的请求响应模块之前，还包括：
    所述Hypervisor获取用户信息，并对所述用户信息第一验证通过；
    所述用户信息为使用所述应用程序的用户的信息。
  5. 根据权利要求4所述的方法，其特征在于，当第一验证不通过时，所述Hypervisor向所述应用程序反馈不能访问所述TrustZone的第二消息。
  6. 根据权利要求4所述的方法，其特征在于，所述Hypervisor获取用户信息，包括：
    所述Hypervisor调用第一用户信息采集设备获取用户信息；
    所述第一用户信息采集设备被所述方法所在终端中各模块调用。
  7. 根据权利要求4所述的方法，其特征在于，所述访问请求还包括用户信息；
    所述Hypervisor获取用户信息，包括：
    所述Hypervisor获取所述访问请求中的用户信息。
  8. 根据权利要求2所述的方法，其特征在于，所述根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用程序能够访问所述TrustZone，包括：
    所述TrustZone的验证模块根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone。
  9. 根据权利要求8所述的方法，其特征在于，在所述验证模块确定所述应用能够访问所述TrustZone之后，在将所述访问请求发送至所述TrustZone的请求响应模块之前，还包括：
    所述验证模块获取用户信息，并对所述用户信息第二验证通过。
  10. 根据权利要求9所述的方法，其特征在于，当第二验证不通过时，所述验证模块向所述应用程序反馈不能访问所述TrustZone的第三消息。
  11. 根据权利要求9所述的方法，其特征在于，所述验证模块获取用户信息，包括：
    所述验证模块调用第二用户信息采集设备获取用户信息；
    所述第二用户信息采集设备被所述TrustZone中各模块调用。
  12. 根据权利要求9所述的方法，其特征在于，所述访问请求还包括用户信息；
    所述验证模块获取用户信息，包括：
    所述验证模块获取所述访问请求中的用户信息。
  13. 根据权利要求2所述的方法，其特征在于，所述根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用程序能够访问所述TrustZone，包括：
    所述Hypervisor根据预设的第一访问策略、所述虚拟机标识和所述应用 标识，确定所述应用能够访问所述TrustZone。
  14. 根据权利要求13所述的方法，其特征在于，在所述Hypervisor确定所述应用能够访问所述TrustZone之后，在将所述访问请求发送至所述TrustZone的请求响应模块之前，还包括：
    所述验证模块根据预设的第二访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone。
  15. 根据权利要求14所述的方法，其特征在于，在所述验证模块确定所述应用能够访问所述TrustZone之后，在将所述访问请求发送至所述TrustZone的请求响应模块之前，还包括：
    所述验证模块获取用户信息，并对所述用户信息第三验证通过。
  16. 根据权利要求15所述的方法，其特征在于，当第三验证不通过时，所述验证模块向所述应用程序反馈不能访问所述TrustZone的第四消息。
  17. 根据权利要求15所述的方法，其特征在于，所述验证模块获取用户信息，包括：
    所述验证模块调用所述第二用户信息采集设备获取用户信息。
  18. 根据权利要求15所述的方法，其特征在于，所述访问请求还包括用户信息；
    所述验证模块获取用户信息，包括：
    所述验证模块获取所述访问请求中的用户信息。
  19. 一种访问控制的装置，其特征在于，所述装置包括：
    接收子模块，用于接收应用程序发送的访问TrustZone的访问请求，所述访问请求包括所述应用程序所在的虚拟机标识，所述应用程序的应用标识；
    第一确定子模块，用于根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用程序能够访问所述TrustZone；
    发送子模块，用于将所述接收子模块接收的访问请求发送至所述TrustZone的请求响应模块。
  20. 根据权利要求19所述的装置，其特征在于，所述装置还包括：
    第一反馈子模块，用于当确定所述应用程序不能访问所述TrustZone时，向所述应用程序反馈不能访问所述TrustZone的第一消息。
  21. 根据权利要求20所述的装置，其特征在于，所述第一确定子模块位于虚拟机监视器Hypervisor中，用于根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone。
  22. 根据权利要求21所述的装置，其特征在于，所述装置，还包括：
    第一获取子模块，所述第一获取子模块位于所述Hypervisor中，用于获取用户信息；
    第一验证子模块，所述第一验证子模块位于所述Hypervisor中，用于对所述第一获取子模块获取的用户信息第一验证通过；
    所述用户信息为使用所述应用程序的用户的信息。
  23. 根据权利要求22所述的装置，其特征在于，所述装置，还包括：
    第二反馈子模块，所述第二反馈子模块位于所述Hypervisor中，用于当第一验证不通过时，向所述应用程序反馈不能访问所述TrustZone的第二消息。
  24. 根据权利要求22所述的装置，其特征在于，所述第一获取子模块，用于调用第一用户信息采集设备获取用户信息；
    所述第一用户信息采集设备被所述方法所在终端中各模块调用。
  25. 根据权利要求22所述的装置，其特征在于，所述访问请求还包括用户信息；
    第一获取子模块，用于获取所述访问请求中的用户信息。
  26. 根据权利要求20所述的装置，其特征在于，所述第一确定子模块位于所述TrustZone的验证模块中，用于根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone。
  27. 根据权利要求26所述的装置，其特征在于，所述装置，还包括：
    第二获取子模块，所述第二获取子模块位于所述验证模块中，用于获取用户信息；
    第二验证子模块，所述第二验证子模块位于所述验证模块中，用于对所 述第二获取子模块获取的用户信息第二验证通过。
  28. 根据权利要求27所述的装置，其特征在于，所述装置，还包括：
    第三反馈子模块，所述第三反馈子模块位于所述验证模块中，用于当第二验证不通过时，向所述应用程序反馈不能访问所述TrustZone的第三消息。
  29. 根据权利要求27所述的装置，其特征在于，所述第二获取子模块，用于调用第二用户信息采集设备获取用户信息；
    所述第二用户信息采集设备被所述TrustZone中各模块调用。
  30. 根据权利要求27所述的装置，其特征在于，所述访问请求还包括用户信息；
    所述第二获取子模块，用于获取所述访问请求中的用户信息。
  31. 根据权利要求20所述的装置，其特征在于，所述第一确定子模块位于所述Hypervisor中，用于根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone。
  32. 根据权利要求31所述的装置，其特征在于，所述装置，还包括：
    第二确定子模块，所述第二确定子模块位于所述验证模块中，用于根据预设的第二访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone。
  33. 根据权利要求32所述的装置，其特征在于，所述装置，还包括：
    第三获取子模块，所述第三获取子模块位于所述验证模块中，用于获取用户信息；
    第三验证子模块，所述第三验证子模块位于所述验证模块中，用于对所述第三获取子模块获取的用户信息第三验证通过。
  34. 根据权利要求33所述的装置，其特征在于，所述装置，还包括：
    第四反馈子模块，所述第四反馈子模块位于所述验证模块中，用于当第三验证不通过时，向所述应用程序反馈不能访问所述TrustZone的第四消息。
  35. 根据权利要求33所述的装置，其特征在于，所述第三获取子模块，用于调用所述第二用户信息采集设备获取用户信息。
  36. 根据权利要求33所述的装置，其特征在于，所述访问请求还包括用户信息；
    所述第三获取子模块，用于获取所述访问请求中的用户信息。
  37. 一种访问控制的系统，其特征在于，所述系统包括：至少一个虚拟机、TrustZone、访问控制的装置；
    所述虚拟机中运行应用程序，当所述应用程序访问所述TrustZone时，向所述访问控制的装置发送访问TrustZone的访问请求，所述访问请求包括所述应用程序所在的虚拟机标识，所述应用程序的应用标识；
    所述访问控制的装置，用于接收所述访问请求；根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用程序能够访问所述TrustZone；将所述访问请求发送至所述TrustZone的请求响应模块；
    所述TrustZone的请求响应模块用于响应所述访问请求。
  38. 根据权利要求37所述的系统，其特征在于，所述访问控制的装置，还用于当确定所述应用程序不能访问所述TrustZone时，向所述应用程序反馈不能访问所述TrustZone的第一消息。
  39. 根据权利要求38所述的系统，其特征在于，所述系统，还包括：虚拟机监视器Hypervisor；
    所述访问控制的装置，位于所述Hypervisor中。
  40. 根据权利要求38所述的系统，其特征在于，所述访问控制的装置，位于所述TrustZone中。
  41. 根据权利要求38所述的系统，其特征在于，所述系统，还包括：Hypervisor；
    所述访问控制的装置，包括第一访问控制子装置和第二访问控制子装置；
    所述第一访问控制子装置，位于Hypervisor中，用于根据预设的第一访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone；
    所述第二访问控制子装置，位于所述TrustZone中，用于在所述第一访问 控制子装置确定所述应用程序能够访问所述TrustZone之后，根据预设的第二访问策略、所述虚拟机标识和所述应用标识，确定所述应用能够访问所述TrustZone；将所述访问请求发送至所述TrustZone的请求响应模块。
PCT/CN2016/077365 2016-03-25 2016-03-25 访问控制的方法、装置和系统 WO2017161569A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201680002731.7A CN107111511B (zh) 2016-03-25 2016-03-25 访问控制的方法、装置和系统
PCT/CN2016/077365 WO2017161569A1 (zh) 2016-03-25 2016-03-25 访问控制的方法、装置和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2016/077365 WO2017161569A1 (zh) 2016-03-25 2016-03-25 访问控制的方法、装置和系统

Publications (1)

Publication Number Publication Date
WO2017161569A1 true WO2017161569A1 (zh) 2017-09-28

Family

ID=59676458

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/077365 WO2017161569A1 (zh) 2016-03-25 2016-03-25 访问控制的方法、装置和系统

Country Status (2)

Country Link
CN (1) CN107111511B (zh)
WO (1) WO2017161569A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112019496A (zh) * 2020-07-06 2020-12-01 浙江华云信息科技有限公司 基于mqtt总线的主题安全订阅方法及装置
CN114003328A (zh) * 2021-11-01 2022-02-01 北京天融信网络安全技术有限公司 数据共享方法、装置、终端设备和桌面云系统

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019148948A1 (zh) * 2018-02-02 2019-08-08 华为技术有限公司 一种内核完整性保护方法及装置
WO2020000145A1 (en) * 2018-06-25 2020-01-02 Intel Corporation World-switch as a way to schedule multiple isolated tasks within a VM
CN111143857B (zh) * 2019-12-27 2022-04-22 达闼机器人有限公司 一种数据分享方法、机器人控制器及存储介质
US11537705B2 (en) * 2020-10-27 2022-12-27 Dell Products L.P. Device access control system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090228967A1 (en) * 2008-03-05 2009-09-10 Microsoft Corporation Flexible Scalable Application Authorization For Cloud Computing Environments
CN105074713A (zh) * 2013-03-15 2015-11-18 赛门铁克公司 用于当连接至网络时识别安全应用程序的系统和方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8375221B1 (en) * 2011-07-29 2013-02-12 Microsoft Corporation Firmware-based trusted platform module for arm processor architectures and trustzone security extensions
CN104063788B (zh) * 2014-07-16 2017-02-22 武汉大学 一种移动平台可信支付系统及方法
CN105335212A (zh) * 2015-10-23 2016-02-17 浪潮电子信息产业股份有限公司 一种基于分布式实施的云计算强制访问控制方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090228967A1 (en) * 2008-03-05 2009-09-10 Microsoft Corporation Flexible Scalable Application Authorization For Cloud Computing Environments
CN105074713A (zh) * 2013-03-15 2015-11-18 赛门铁克公司 用于当连接至网络时识别安全应用程序的系统和方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112019496A (zh) * 2020-07-06 2020-12-01 浙江华云信息科技有限公司 基于mqtt总线的主题安全订阅方法及装置
CN112019496B (zh) * 2020-07-06 2023-09-19 浙江华云信息科技有限公司 基于mqtt总线的主题安全订阅方法及装置
CN114003328A (zh) * 2021-11-01 2022-02-01 北京天融信网络安全技术有限公司 数据共享方法、装置、终端设备和桌面云系统
CN114003328B (zh) * 2021-11-01 2023-07-04 北京天融信网络安全技术有限公司 数据共享方法、装置、终端设备和桌面云系统

Also Published As

Publication number Publication date
CN107111511B (zh) 2021-09-14
CN107111511A (zh) 2017-08-29

Similar Documents

Publication Publication Date Title
US11693951B2 (en) Method and apparatus for applying application context security controls for software containers
WO2017161569A1 (zh) 访问控制的方法、装置和系统
US11093604B2 (en) Personalized and cryptographically secure access control in trusted execution environment
US8639926B2 (en) Techniques for mobile device authentication
US8935746B2 (en) System with a trusted execution environment component executed on a secure element
EP3326103B1 (en) Technologies for trusted i/o for multiple co-existing trusted execution environments under isa control
US8856512B2 (en) Method and system for enterprise network single-sign-on by a manageability engine
CN108140094B (zh) 用于安全可信i/o访问控制的技术
US9514313B2 (en) Techniques for secure data extraction in a virtual or cloud environment
EP3014847B1 (en) Secure hybrid file-sharing system
US8826391B2 (en) Virtualized trusted descriptors
EP2973171B1 (en) Context based switching to a secure operating system environment
CN106330958B (zh) 一种安全访问方法及装置
US10375109B2 (en) Protecting personally identifiable information from electronic user devices
WO2017167019A1 (zh) 基于云桌面的处理方法、装置及计算机存储介质
KR101654778B1 (ko) 하드웨어 강제 액세스 보호
JP2016506107A (ja) 仮想マシンのための管理制御方法、装置及びシステム
CN105069383A (zh) 一种云桌面usb存储外设管控的方法及系统
WO2020186457A1 (zh) 网络摄像机的认证方法和装置
WO2019205389A1 (zh) 电子装置、基于区块链的身份验证方法、程序和计算机存储介质
US20150264047A1 (en) Method and system for providing secure communication between multiple operating systems in a communication device
EP4172818B1 (en) Shared resource identification
US8601544B1 (en) Computer system employing dual-band authentication using file operations by trusted and untrusted mechanisms
US10110683B2 (en) Systems and methods for maintaining ownership of and avoiding orphaning of communication sessions
CN110971670B (zh) 一种基于网证平台的网证调用方法、装置及存储介质

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16894923

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 16894923

Country of ref document: EP

Kind code of ref document: A1