Method, device and computer program product for verifying an IoT device

Abstract

The embodiment of the invention provides a method, equipment and a computer program product for verifying Internet of Things equipment. The method includes establishing a TPM-like environment in a trusted execution environment (TEE) of the Internet of Things device in response to startup of a TPM simulator. The method also includes sending an access request to an application in the Internet of Things device through a direct anonymous verification (DAA) simulator in the TEE. In addition, the method further includes, in response to receiving a response received from the cloud platform by the application program, performing verification of the Internet of Things device through the TPM simulator. Through the method, the required TPM security service is simulated in the TEE of the Internet of Things equipment, so that the privacy information of a user is not exposed as much as possible while verification is completed, and the verification security is ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of Internet of Things, and more particularly, to a method, device and computer program product for verifying an Internet of Things device. BACKGROUND

[0002] When an Internet of Things device is installed, upgraded, and the like, it is verified to ensure that the version, hardware information, and the like of the device are not compromised and that the device is authentic.

[0003] To complete the verification, a large amount of information about the Internet of Things device is sent to the provider of the security chip on the device. This verification process risks exposing the purchaser's own privacy information, and thus, business plans and trade secrets. SUMMARY

[0004] Embodiments of the present application provide a method, device and computer program product for verifying an Internet of Things device.

[0005] According to a first aspect of embodiments of the present application, a method for verifying an Internet of Things device is provided, comprising: in response to starting of a Trusted Platform Module (TPM) emulator, establishing a TPM-like environment in a Trusted Execution Environment (TEE) of the Internet of Things device; sending an access request to an application in the Internet of Things device through a Direct Anonymous Attestation (DAA) emulator in the TEE; and in response to receiving a response from the application received from a cloud platform, performing verification of the Internet of Things device through the TPM emulator.

[0006] According to a second aspect of embodiments of the present application, an electronic device is provided, comprising:

[0007] at least one processor; and coupled to the at least one processor and having stored thereon instructions which, when executed by the at least one processor, cause the electronic device to perform actions comprising: in response to starting of a Trusted Platform Module (TPM) emulator, establishing a TPM-like environment in a Trusted Execution Environment (TEE) of the Internet of Things device; sending an access request to an application in the Internet of Things device through a Direct Anonymous Attestation (DAA) emulator in the TEE; and in response to receiving a response from the application received from a cloud platform, performing verification of the Internet of Things device through the TPM emulator.

[0008] According to a third aspect of embodiments of the present application, there is provided a computer program product tangibly stored on a non-transitory computer readable medium and comprising machine executable instructions that, when executed, cause a machine to perform actions comprising: in response to a launch of a trusted platform module (TPM) emulator, establishing a TPM-like environment in a trusted execution environment (TEE) of an Internet of Things (IoT) device; sending an access request to an application in the IoT device through a direct anonymous attestation (DAA) emulator in the TEE; and in response to receiving a reply from the application received from a cloud platform, performing an attestation of the IoT device through the TPM emulator.

[0009] It is to be understood that the description of the summary section is not intended to define key or essential features of embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0010] The above and other features, advantages and aspects of embodiments of the present disclosure will become more apparent by describing in detail some embodiments thereof with reference to the annexed drawings in which:

[0011] Figure 1 is a schematic diagram of a trust chain of a boot process of a device with a TPM chip;

[0012] Figure 2 shows a schematic diagram of a current Internet of Things (IoT) device attestation process;

[0013] Figure 3 shows a schematic diagram of an environment for implementing some embodiments of the present disclosure;

[0014] Figure 4 shows a flowchart of a method for attesting an IoT device according to some embodiments of the present disclosure; and

[0015] Figure 5 shows a schematic diagram of a first-time attestation process of an IoT device according to some embodiments of the present disclosure.

[0016] Figure 6 shows a schematic diagram of a runtime attestation process of an IoT device according to some embodiments of the present disclosure.

[0017] Figure 7 shows a schematic block diagram of an example device to implement embodiments of the present disclosure. DETAILED DESCRIPTION

[0018] Embodiments of the present disclosure will be described below in greater detail with reference to the accompanying drawings. While certain embodiments of the present disclosure are shown in the drawings, it is understood that the present disclosure can be embodied in various forms and should not be construed as being limited to the embodiments set forth herein, but rather, the embodiments are provided so that the present disclosure can be more thoroughly and completely understood. It should be understood that the drawings and embodiments of the present disclosure are only for illustrative purposes and are not intended to limit the scope of protection of the present disclosure.

[0019] In the description of embodiments of the present disclosure, the terms "include", "have", and their conjugates should be understood to be open terms that mean "including but not limited to". The term "based on" should be understood as "based at least in part on". The terms "embodiment", "one embodiment", or "the embodiment" should be understood as "at least one embodiment".

[0020] In the security verification process of an Internet of Things device, a large amount of information about the device is usually sent to the supplier (verifier) of the security chip carried by the device to complete the security verification. Through this information, the verifier can clearly identify the detailed information of the device being verified, thereby obtaining a series of information about the device and the purchaser of the device, which may be the user's private information.

[0021] The current mainstream security verification of Internet of Things devices uses TPM chips, which are chips implanted in computers to provide trusted roots for computers. The specifications of the chip are developed by the Trusted Computing Group. Although TPM chips can perform a wide range of encryption, they are not carried by many Internet of Things devices due to their limitations in space, cost, and power consumption. In fact, ARM chipsets are currently commonly used in Internet of Things devices. ARM TrustZone provides a runtime environment that is isolated from other software on the platform, including the operating system, applications, and most firmware, which makes it possible to implement security services that provide security guarantees similar to security co-processors such as TPM.

[0022] On the other hand, the current security verification of Internet of Things devices is based on software and does not have hardware-based certificates, security labels, or trusted markers. If the firmware / application of an Internet of Things device is compromised, the software-based security verification method can be tampered with. In addition, since Internet of Things devices are usually placed in relatively insecure environments (public areas, outdoors, etc., compared to servers in computer rooms), they are more likely to be directly accessed by hackers. Not only the hardware and underlying layers of the device (the device code provided by the device manufacturer when the device is shipped), but also the application designed at the user level is at risk of being attacked and modified.

[0023] In this disclosure, a scheme for verifying Internet of Things devices is proposed. In embodiments of the disclosure, by simulating the required TPM security services in the TEE of the Internet of Things device, the user's privacy information is as much as possible not exposed while completing the verification, and a verification protection idea is also proposed for the application program code of the user application layer.

[0024] Figure 1 is a schematic diagram of a trust chain 100 of a device with a TPM chip. As Figure 1 shown, the trust chain 100 is established by verifying each hardware and software component from the terminal entity to the root certificate. In some embodiments, the trust chain 100 aims to ensure that only trusted software and hardware can be used. In Figure 1 the device startup process shown, each component is subjected to security verification, and this verification has a sequential relationship, that is, the verification of the next component is based on the combination of its own digital signature and the digital signatures of all previously verified components. As Figure 1 shown, the digital signature of the firmware will first be verified by the TPM, thereby reducing the risk of firmware rootkits. Then, for all code running before the operating system, the digital signature of the loader is checked by the TPM, thereby ensuring that these codes are trusted. Next, the trusted startup program runs and verifies the digital signature of the kernel and the startup device (including startup processes, boot drivers, startup files).

[0025] In this device startup process, the hash of the binary file is extended to the platform configuration register (PCR). The extension corresponds to the hash of the connection of the previous content of the PCR and the input hash, and the result is stored in the PCR. This device startup process defines a startup sequence (trust chain) that prevents unauthorized or modified code from running during the startup process. In this process, the TPM acts as the root of trust for the platform, securely stores key material and platform measurements, thereby protecting the security of the hardware and ensuring that the platform remains trusted.

[0026] Figure 2 shows a schematic diagram of the current Internet of Things device verification process 200. As Figure 2As shown, the company 202 installs a large number of cameras, and when these cameras are configured and security verification processes, first sends its information for configuration and verification to the cloud platform 206 in the process 204, which includes specific device information, network address, actual geographical location of deployment, scale number of deployed devices, etc. Then, the cloud platform 206 sends this information to the vendor device 210 in the process 208. Since the current Internet of Things device verification process 200 is completely controlled and managed by the vendor device 210, it can lead to leakage of customer privacy data. For example, the company 202 purchases a large number of monitoring cameras and deploys these devices to an area. Each time the device is installed or security verification is performed, the vendor device obtains detailed information of the device's digital / geographical data. This information is highly sensitive and can leak the company's trade secrets.

[0027] Figure 3 An environment 300 schematic diagram for implementing some embodiments of the present disclosure is shown. In Figure 3 The environment 300 includes a cloud platform 302 and an Internet of Things device 304. Among them, the cloud platform is composed of the operating systems and hardware of various servers in a data center, which can provide cloud computing services for customers after configuration, allowing enterprises to rent access to computing resources on demand through the Internet. The Internet of Things device 304 is a non-standard computing device that can be connected to the network wirelessly or wiredly and has the ability to transmit data. The Internet of Things device 304 includes an application 310 running inside it and a TEE, where the TEE includes a DAA emulator and a TPM emulator.

[0028] The Internet of Things device 304 can be divided into wired Internet of Things devices and wireless Internet of Things devices according to different network connection methods. Wired Internet of Things devices usually refer to devices that connect to the network through network cables and Ethernet, commonly used in industrial and commercial fields, such as gateways, switches, industrial robots, surveillance cameras, etc. Wireless Internet of Things devices refer to devices that connect to the network through 4G, WIFI, Bluetooth, etc., and are used in life, industry, commerce, etc., such as industrial gateways, smart speakers, smart homes.

[0029] The functions of the Internet of Things device 304 include: 1) data collection and transmission: collecting environmental data through sensors and sending data to the cloud or other devices through Internet of Things technology. 2) Online monitoring and positioning tracking: monitor the running state of the device and realize the positioning tracking of the device through wireless communication technology, GPS system, etc. 3) Remote control and operation: through Internet of Things technology, the Internet of Things device can be remotely controlled and operated. 4) Data processing and analysis: the Internet of Things device can process and analyze the collected data to provide real-time information and feedback. 5) Automation and intelligence: the Internet of Things device can realize automatic control, upgrading, and intelligent application through intelligent algorithms and control systems, etc.

[0030] The TEE 312 in the IoT device 304 is a separate area on the CPU processor that is isolated from other parts of the CPU using encryption techniques. This area can only be accessed and used for computation after a series of verifications through the interface of the TEE service provided by the processor vendor itself. The TEE 312 runs on top of a normal operating system and can operate data in the TEE 312 through properly authorized code, as it provides a trusted secure environment in which any data cannot be read or tampered with by any code outside of the environment, ensuring the security and privacy of sensitive data and code.

[0031] The TPM emulator 314 in the TEE 312 is a simulated implementation of a TPM. A TPM is a computer chip (microcontroller) that can securely store components used to authenticate a platform (IoT device, computer, laptop). These components can include passwords, certificates, or encryption keys. A TPM can also be used to store platform measurements that help ensure that the platform remains trustworthy. A device containing a TPM can create encryption keys and encrypt them so that the keys can only be decrypted by the TPM. Each TPM has a master wrapping key, called the storage root key, which is stored in the TPM itself. The private portion of the storage root key created in the TPM is never exposed to any other component, software, process, or user. It can be specified whether the encryption keys created by the TPM can be migrated. If it is specified that the keys can be migrated, the public and private portions of the keys can be exposed to other components, software, processes, or users. A device containing a TPM can also create a key that is wrapped and bound to certain platform measurements. This type of key can only be unwrapped when the platform measurements have the same value as when the key was created. This process is called sealing. The decryption of the key is called unsealing. A TPM can also seal and unseal data generated outside of the TPM. The data can be locked using a sealing key and software. The TPM processes instructions using its own internal firmware and logic circuitry. Therefore, it is not dependent on the operating system and is not exposed to vulnerabilities that can exist in the operating system or application software. In embodiments of the present disclosure, the TPM emulator 314 can implement the features of a TPM, including but not limited to the TPM features described herein.

[0032] The DAA emulator 316 in the TEE 312 is a simulated implementation of a DAA that is specifically designed to adapt to the TPM. A DAA is a remote attestation protocol used to verify the legitimate identity of a TPM. The DAA protocol is divided into three entities, a certificate issuer, a signer, and a signature verifier, the signer includes a host and a TPM, the TPM prevents intrusion by unauthorized users, and the host is responsible for message passing between the TPM and other entities and bears part of the computation task.

[0033] DAA protocols are a special type of group signature protocol, unlike general group signatures (where an authority, such as an administrator in the group or other trusted third party, can reveal who the true signer is from the signature), DAA has flexible traceability and linkability, because there is no authority in the protocol to reveal identity. DAA can provide a mechanism for user anonymity and user-controlled linkability, such that multiple intended signatures from the same signer are linkable to the same or multiple verifiers. In embodiments of the present disclosure, DAA emulator 316 can implement the properties of DAA, including but not limited to the DAA properties described herein.

[0034] Cloud platform 302 can create a virtual shared resource pool, using virtualization technology to create multiple virtual machines on a single server, so as to be able to run separate operating systems and applications for different customers on a physical server. It provides computing, data storage and network services over the Internet, allowing enterprises to store, backup and restore data; test and build applications; access cloud databases; analyze large data sets; deliver software on demand at a global scale; access business intelligence; and create cloud-native applications, etc. Customers can access resources on cloud platform 302 when needed, and only pay for the resources they need.

[0035] Cloud platform 302 can be classified by its service objects into private cloud platforms and public cloud platforms, where private cloud platforms are cloud computing environments exclusively for use by one enterprise, which can be owned and managed by the enterprise or rented from a private cloud service provider; public cloud platforms are operated by cloud service providers (third-party providers who own and are responsible for managing and upgrading the hardware and software of the cloud platform), and provide services to multiple customers through virtual machines, which are located on the same physical server and are isolated from each other. Both public and private cloud platforms can provide all the advantages of cloud computing, including flexibility, allowing enterprises to quickly expand and shrink their scale according to business needs, thereby avoiding the risk of over-provisioning or under-provisioning; low cost, allowing enterprises to avoid capital expenditures for setting up local data centers, and also avoiding IT labor costs related to management; strong performance, allowing enterprises to access all the computing power and cloud storage space they need, thereby enabling enterprises to have exceptional performance; high agility, providing on-demand resources that allow enterprises to deploy cloud infrastructure they actually need at any time, to speed up innovation and product launch; fast deployment, allowing enterprises to deploy the technology they need anywhere in the world, and only takes a few minutes to complete, rather than days, weeks or even months; and strong security, excellent reliability, advanced mobility, etc.

[0036] In Figure 3In the illustrated embodiment, when the IoT device 304 is powered on, the TPM emulator is also started, thereby establishing a TPM-like environment in the TEE 312 to provide a secure runtime environment. In response to the start of the TPM emulator 314, an access request is sent by the DAA emulator 316 to the application 310. The application 310 sends the received access request to the cloud platform 302. The cloud platform 302 forwards the access request to the supplier of the IoT device 304, and upon receiving the supplier-signed access request, sends a response of the supplier to the application 310. The application 310 sends the received response to the TEE 312, and performs a verification process of the IoT device 304 through the TPM emulator. The verification process includes a first-time verification process and a runtime verification process.

[0037] In this way, a TPM service is emulated in the TEE of the IoT device, thereby implementing a DAA and a corresponding verification process, so that even an IoT device without a TPM chip but with a TEE can implement a more secure verification process.

[0038] Figure 4 A flowchart of a method 400 for verifying the IoT device 304 according to some embodiments of the present disclosure is shown. The method 400 can be implemented in the environment 300 shown. Figure 3 The numbering in the flowchart does not indicate the order in which the steps are performed, some or all of the steps can be performed in parallel, or the order of execution can be interchanged, which is not limited by the present disclosure.

[0039] In block 402, in response to the start of the trusted platform module (TPM) emulator, a TPM-like environment is established in the trusted execution environment (TEE) of the IoT device; an access request is sent by a direct anonymous attestation (DAA) emulator in the TEE to an application in the IoT device; and in response to receiving a response of the application received from a cloud platform, a verification of the IoT device is performed through the TPM emulator.

[0040] In some embodiments, in response to the launch of the TPM emulator 314, a TPM-like environment is established in the TEE 312 of the IoT device 304. To enable invocation of TPM commands, a handler is introduced at the secure side of the TEE 312 as a custom layer to handle the business logic. The handler receives an identifier from a client and finds a target service, then executes the target code consisting of business logic and TPM commands, and finally invokes the TPM emulator 314 in the TEE 312 and submits the commands to the command entry of the TPM emulator 314 and gets these TPM services. The TPM emulator 314 works as a trusted application at the trusted side of the TEE 312. It passes the requested TPM command from the TEE 312 to a command dispatcher upon receiving it, which searches a command descriptor table and finds the actual TPM command entry that will provide the service eventually and finally executes the TPM command. In this way, an environment is implemented that can execute TPM commands.

[0041] In block 404, an access request is sent to an application in the IoT device by a DAA emulator in the TEE. In some embodiments, an access request is sent to the application 310 in the IoT device 304 by the DAA emulator 316 in the TEE 312. To implement DAA in the TEE 312, the TPM emulator 314 interface is used to mark the TPM signature operation with an identifier TPM2_CC_Sign and forward the identifier to the entry of the TPM emulator 314 to get the TPM signature service. The access request sent by the DAA emulator 316 is a request signed by the DAA emulator 316. In the process of signing by the DAA emulator 316, the TPM emulator 314 is verified by a certificate issuer and issued a DAA credential, and the credential is verified by a signature verifier without attempting to compromise the host privacy. At the same time, the DAA emulator 316 also supports a blacklist function so that the signature verifier can identify the proof from a compromised TPM emulator 314.

[0042] In block 406, verification of the IoT device is performed by the TPM emulator in response to receiving a reply from the cloud platform received by the application. In some embodiments, verification of the IoT device 304 is performed by the TPM emulator 314 in response to receiving a reply from the cloud platform 302 received by the application 310. The reply is from the supplier of the IoT device 304 signed access request, and the verification performed by the TPM emulator 314 includes first-time verification and runtime verification. The TPM emulator 314 acts as a root of trust in the verification process, establishing a chain of trust for the verification process.

[0043] Figure 5 A schematic diagram showing a first-time verification process 500 of the IoT device 304 according to some embodiments of the present disclosure is shown. As shown in FIG. 5, the first-time verification process 500 includes the following steps:Figure 5 As shown, the first verification process 500 involves four execution subjects, including a vendor device 502, a cloud platform 504, an end-user application 506 and an IoT device 508. The vendor device 502, the end-user application 506 and the IoT device 508 respectively interact with the cloud platform 504. The end-user application 506 includes a verification interface 506-1, the cloud platform 504 includes a verification agent 504-1 for transmitting verification related information and a zero trust interface 504-2 for providing zero trust support in a runtime verification process. The vendor device 502 includes a verification interface 502-1, and the IoT device 508 includes a hardware-based security tag generation 508-1, an operating system 508-2, a TEE 508-3 and a firmware 508-4.

[0044] The vendor device 502 is a vendor device of the IoT device 508, including a distributor device and a manufacturer device. The distributor device can be a notebook computer, a server, etc., used to record a sold transaction of the IoT device 508; wherein the sold transaction includes a manufacturer identity, a distributor identity, a purchaser and an identity of the IoT device 508. Through the sold transaction recorded by the distributor device, the manufacturer, the distributor, the IoT device 508 and the purchaser can be bound; the purchaser is the user. The sold transaction can be used for subsequent user tracing of the IoT device 508. The manufacturer device can be a notebook computer, a server, etc., used to enable the manufacturer to write a registration transaction of the IoT device 508 into a blockchain after the production and assembly of the IoT device 508 are completed. The registration transaction includes a globally unique device identity of the IoT device, basic information (such as a manufacturer identity, a model, etc.) of the IoT device.

[0045] In Figure 5In the illustrated embodiment, the end user application 506 first registers the IoT device 508 to the cloud platform 504. Upon receiving an access request from the IoT device 508, the cloud platform 504 forwards the access request to the vendor device 502, which contains the hardware information of the IoT device 508. The vendor device 502 receives the access request sent from the cloud platform 504 through the verification interface 502-1. After signing the access request, the vendor device 502 sends a response to the cloud platform 504 through the verification interface 502-1. The cloud platform 504 forwards the response to the IoT device 508, and upon receiving the response, the IoT device 508 has the private key of the DAA signature registered to the vendor device 502. Next, the IoT device 508 sends a first verification configuration request for the configuration of the IoT device 508 to the cloud platform 504, as well as the identity of the application and the PCR value signed with the private key. The cloud platform 504 sends the first verification configuration request to the end user application 506, and upon receiving the request through the verification interface 506-1, the end user application 506 verifies the firmware 508-4, the operating system 508-2 and the application in the IoT device 508 based on the PCR value. After the end user application 506 completes the verification, the end user application 506 sends the first verification configuration and the first verification information to the cloud platform 504 through the verification interface 506-1. The cloud platform 504 sends the first verification configuration to the IoT device 508. Finally, the IoT device 508 applies the first verification configuration on the application to complete the first verification.

[0046] Figure 6 A schematic diagram illustrating a verification process 600 of an IoT device runtime according to some embodiments of the present disclosure is shown. As Figure 6 The runtime verification process 600 involves two execution subjects, including the cloud platform 504 and the IoT device 508, as

[0047] As Figure 6 The cloud platform 504 sends a verification request to the IoT device 508, which includes one or more of a data verification request, a device verification request and a program verification request. For the data verification request, a secure channel is established between the IoT device 508 and the cloud platform 504 by the TPM emulator using the key generated from the TPM emulator; for the device verification request, the PCR value signed by the DAA emulator is sent to the cloud platform 504 by the IoT device 508; for the program verification request, the hash code of the application signed by the DAA emulator is sent to the cloud platform 504 by the IoT device 508.

[0048] By Figure 5 and Figure 6The embodiments shown provide mechanisms and procedures for security verification of IoT devices, which are designed to simulate the required TPM security services in the TEE for IoT devices that do not have TPMs, so as to complete the verification while exposing the user's privacy information as little as possible, ensuring the security of the verification process.

[0049] Figure 7 A schematic block diagram of an example device 700 that can be used to implement embodiments of the present disclosure is shown. As shown, the device 700 includes a processor 701 that can perform various appropriate actions and processes in accordance with computer program instructions stored in a read-only memory (ROM) 702 or loaded into a random access memory (RAM) 703 from a storage unit 708. Various programs and data required for operation of the device 700 can also be stored in the RAM 703. The processor 701, the ROM 702, and the RAM 703 are connected to each other through a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0050] A plurality of components in the device 700 are connected to the I / O interface 705, including: an input unit 706, such as a keyboard, a mouse, etc.; an output unit 707, such as various types of displays, speakers, etc.; a storage unit 708, such as a magnetic disk, an optical disk, etc.; and a communication unit 709, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 709 allows the device 700 to exchange information / data with other devices through a computer network, such as the Internet, and / or various telecommunication networks.

[0051] The processor 701 can be various general and / or special purpose processing components with processing and computing capabilities. Some examples of the processor 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 701 performs various methods and processes described above, such as the method 200. For example, in some embodiments, the method 200 can be implemented as a computer software program that is tangibly embodied in a machine-readable medium, such as the storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed on the device 700 via the ROM 702 and / or the communication unit 709. When the computer program is loaded into the RAM 703 and executed by the processor 701, one or more steps of the method 200 described above can be performed. Alternatively, in other embodiments, the processor 701 can be configured to perform the method 200 by any other appropriate means, such as by means of firmware.

[0052] The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, and without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), and the like.

[0053] The program code for implementing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device so that when the program code is executed by the processor or controller, the functions / operations specified in the flow chart and / or block diagram are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0054] 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 conjunction with an instruction execution system, device, or apparatus. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or apparatus, or any suitable combination of the foregoing. More specific examples of machine-readable storage media may include an electrical connection based on one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In addition, although each operation is depicted in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in a sequential order, or requiring that all illustrated operations be performed to obtain the desired result. In certain environments, multitasking and parallel processing may be advantageous. Likewise, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of separate embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented in multiple implementations individually or in any suitable subcombination.

[0055] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A method for verifying an Internet of Things device, the method comprising: in response to a launch of a Trusted Platform Module (TPM) emulator, establishing a TPM-like environment in a Trusted Execution Environment (TEE) of the Internet of Things device; sending an access request to an application in the Internet of Things device through a Direct Anonymous Attestation (DAA) emulator in the TEE; and in response to receiving a reply from the application received from a cloud platform, performing verification of the Internet of Things device through the TPM emulator.

2. The method of claim 1, wherein the reply received from the cloud platform is from an operation of a vendor device, the operation comprising: in response to receiving the access request from the cloud platform, the vendor device signing the access request and sending a reply thereof to the cloud platform.

3. The method of claim 1, wherein performing verification of the Internet of Things device through the TPM emulator comprises: in response to receiving the reply from the cloud platform, the Internet of Things device having a private key registered to a DAA signature of a vendor device; sending, by the Internet of Things device, a first verification configuration request for configuration of the Internet of Things device to the cloud platform, and an identity of the application and a Platform Configuration Register (PCR) value signed with the private key to the cloud platform; and in response to receiving a first verification configuration from the cloud platform, the Internet of Things device applying the first verification configuration on the application.

4. The method of claim 3, wherein the first verification configuration from the cloud platform is from an operation of an end user application, the operation comprising: in response to receiving the first verification configuration request from the cloud platform, the end user application verifying firmware, an operating system, and the application in the Internet of Things device based on the PCR value; and sending, by the end user application, the first verification configuration and first verification information to the cloud platform.

5. The method of claim 1, further comprising: in response to receiving a verification request from the application received from the cloud platform, performing runtime verification of the Internet of Things device through the TPM emulator.

6. The method of claim 5, wherein the verification request comprises one or more of a data verification request, a device verification request, and a program verification request.

7. The method of claim 5, wherein performing runtime verification of the Internet of Things device through the TPM emulator comprises: in response to a data verification request, establishing, by the TPM emulator, a secure channel between the Internet of Things device and the cloud platform using a key generated from the TPM emulator; in response to a device verification request, sending, by the Internet of Things device, a platform configuration register value signed by the DAA emulator to the cloud platform; and in response to a program verification request, sending, by the Internet of Things device, a hash code of the application signed by the DAA emulator to the cloud platform.

8. An electronic device, the electronic device comprising: at least one processor; and ​ a memory coupled to the at least one processor and having instructions stored thereon that, when executed by the at least one processor, cause the electronic device to perform actions comprising: in response to initiation of a trusted platform module (TPM) emulator, establishing a TPM-like environment in a trusted execution environment (TEE) of an internet of things (IoT) device; sending an access request to an application in the IoT device through a direct anonymous attestation (DAA) emulator in the TEE; and in response to receiving a reply from the application received from a cloud platform, performing attestation of the IoT device through the TPM emulator.

9. The device of claim 8, wherein the reply received from the cloud platform is from an operation of a vendor device, the operation comprising: in response to receiving the access request of the cloud platform, the vendor device signing the access request and sending a reply thereof to the cloud platform.

10. The device of claim 8, wherein performing attestation of the IoT device through the TPM emulator comprises: in response to receiving the reply from the cloud platform, the IoT device having a private key registered to a DAA signature of a vendor device; sending, by the IoT device to the cloud platform, a first attestation configuration request for configuration of the IoT device, and an identity of the application and a platform configuration register (PCR) value signed with the private key; and in response to receiving a first attestation configuration from the cloud platform, the IoT device applying the first attestation configuration on the application.

11. The device of claim 10, wherein the first attestation configuration from the cloud platform is from an operation of an end user application, the operation comprising: in response to receiving the first attestation configuration request from the cloud platform, the end user application verifying firmware, an operating system, and the application in the IoT device based on the PCR value; and sending, by the end user application to the cloud platform, the first attestation configuration and first attestation information.

12. The device of claim 8, wherein the actions further comprise: in response to receiving an attestation request from the application received from the cloud platform, performing runtime attestation of the IoT device through the TPM emulator.

13. The device of claim 12, wherein attestation request comprises one or more of a data attestation request, a device attestation request, and a program attestation request.

14. The device of claim 12, wherein performing runtime attestation of the IoT device through the TPM emulator comprises: in response to a data attestation request, establishing, by the TPM emulator, a secure channel between the IoT device and the cloud platform with a key generated from the TPM emulator; in response to a device attestation request, sending, by the IoT device to the cloud platform, a platform configuration register value signed by the DAA emulator; and in response to a program attestation request, sending, by the IoT device to the cloud platform, a hash code of the application signed by the DAA emulator. ​ 15. A computer program product tangibly stored on a non-transitory computer readable medium and comprising machine executable instructions that, when executed, cause a machine to perform acts comprising: in response to a launch of a trusted platform module (TPM) emulator, establishing a TPM-like environment in a trusted execution environment (TEE) of an Internet of Things (IoT) device; sending an access request to an application in the IoT device through a direct anonymous attestation (DAA) emulator in the TEE; and in response to receiving a reply from the application received from a cloud platform, performing attestation of the IoT device through the TPM emulator.

16. The computer program product of claim 15, wherein the reply received from the cloud platform is from operations of a vendor device comprising: in response to receiving the access request of the cloud platform, the vendor device signing and sending a reply to the access request to the cloud platform.

17. The computer program product of claim 15, wherein performing attestation of the IoT device through the TPM emulator comprises: in response to receiving the reply from the cloud platform, the IoT device having a private key registered to a DAA signature of a vendor device; sending, by the IoT device to the cloud platform, a first attestation configuration request for configuration of the IoT device, and an identity of the application and a platform configuration register (PCR) value signed with the private key; and in response to receiving a first attestation configuration from the cloud platform, the IoT device applying the first attestation configuration on the application.

18. The computer program product of claim 17, wherein the first attestation configuration from the cloud platform is from operations of an end user application comprising: in response to receiving the first attestation configuration request from the cloud platform, the end user application verifying firmware, an operating system, and the application in the IoT device based on the PCR value; and sending, by the end user application to the cloud platform, the first attestation configuration and first attestation information.

19. The computer program product of claim 15, the acts further comprising: in response to receiving an attestation request from the cloud platform received by the application, performing runtime attestation of the IoT device through the TPM emulator.

20. The computer program product of claim 15, wherein performing runtime attestation of the IoT device through the TPM emulator comprises: in response to a data attestation request, establishing, by the TPM emulator, a secure channel between the IoT device and the cloud platform using a key generated from the TPM emulator; in response to a device attestation request, sending, by the IoT device to the cloud platform, a platform configuration register value signed by the DAA emulator; and in response to a program attestation request, sending, by the IoT device to the cloud platform, a hash code of the application signed by the DAA emulator.

Images