阅读说明：本技术 装置利用云平台的安全登记 (Secure enrollment of devices using cloud platform ) 是由 R·古普塔 杨雪晨 臧铁飞 石学林 于 2018-08-17 设计创作，主要内容包括：提供一种用于装置利用云平台进行安全登记的机制。这充当保护可以从云供应和管理的装置的安全的基础,例如边缘计算和物联网网关。提供一种公共密钥基础设施机制用于进行分成三个阶段的登记。安全登记过程的第一和第二阶段认证所述装置并确保所述装置符合装置制造商的制造限制。安全登记过程的第三阶段向所述装置提供长期操作证书以供云资源访问。(A mechanism is provided for secure enrollment of devices with a cloud platform. This serves as a basis for securing the security of devices that can be provisioned and managed from the cloud, such as edge computing and internet of things gateways. A public key infrastructure mechanism is provided for performing registration in three phases. The first and second phases of the secure enrollment process authenticate the device and ensure that the device complies with the device manufacturer's manufacturing limitations. The third phase of the secure enrollment process provides the apparatus with long-term operational credentials for access by cloud resources.)

1. A multi-phase method for registering a network device with a network service, the method comprising:

during a first phase, obtaining, by the network device, a first temporary digital certificate from a first network server using first information stored in the network device during manufacture of the network device;

during a second phase, obtaining, by the network device, one of a second temporary digital certificate or an e-token from a second network server using the first temporary digital certificate and second information stored in the network device during manufacture of the network device; and

during a third phase, obtaining, by the network device, a long-term digital certificate from a third network server using the one of a second temporary digital certificate or an e-token, wherein the network device is configured to communicate with the network service using the long-term digital certificate.

2. The method of claim 1, wherein the first stage comprises:

communicating with the first network server using a secure communication protocol;

transmitting a shared boot secret to the first network server, wherein the first information comprises the shared boot secret; and

receiving the first temporary digital certificate from the first network server in response to the first network server authenticating the shared boot secret.

3. The method of claim 2, wherein the connecting with the first network server further comprises:

establishing secure communications using the secure communication protocol using information in a registration Certificate Authority (CA) certificate, wherein the first information further includes the registration CA certificate.

4. The method of claim 1, wherein the second stage comprises:

communicating with the second network server using a secure communication protocol;

transmitting the first temporary digital certificate to the second network server;

transmitting the second information stored in the network device to the second network server;

receiving the second temporary digital certificate or etoken from the second network server in response to the second network server authenticating the first temporary digital certificate and the second information.

5. The method of claim 4, wherein the second information comprises one or more of the following

A unique identifier of the device;

a unique identifier of a manufacturer of the device;

a unique identifier of a model of the device; and

a key generated by or securely programmed on the device, wherein the public portion of the key is accessible to the second network server.

6. The method of claim 5, wherein the second network server authenticating the second information comprises:

comparing the second information with manufacturer-related information stored at the second network server;

providing the authentication in response to the second information complying with the manufacturer-related information.

7. The method of claim 6, wherein the comparing the second information to manufacturer-related information stored at the second network server comprises:

associating the network device with a manufacturer of the network device, wherein the second information comprises a manufacturer identifier; and

determining whether the network device is within an allowed number of devices manufactured by the manufacturer of the network device.

8. The method of claim 6, wherein the comparing the second information to manufacturer-related information stored at the second network server comprises:

associating the network device with a device type, wherein the second information comprises a device type identifier; and

determining whether the network device is within an allowed number of devices of the device type.

9. The method of claim 6, wherein the comparing the second information to manufacturer-related information stored at the second network server comprises:

associating the network device with a manufacturer of the network device, wherein the second information comprises a security key associated with the manufacturer; and

determining whether the network device is a device from the manufacturer by using a public portion of the security key stored at the second network server.

10. A method for registering a network device with a network service, the method comprising:

obtaining, by the network device, a first temporary digital certificate or e-token from a first network server using a second digital certificate and information stored in the network device during manufacture of the network device; and

obtaining, by the network device, a long-term digital certificate from a second network server using the first temporary digital certificate or an e-token, wherein the network device is configured to communicate with the network service using the long-term digital certificate.

Technical Field

The present disclosure relates generally to cloud computing, and more specifically to mechanisms for device full registration with a cloud platform.

Background

Cloud computing is provided on shared computing resources rather than processing applications with local servers or personal devices. Cloud computing may enable convenient and on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that may be provisioned and released quickly. Different cloud-based services delivered through cloud computing resources include (for example): software as a service (SaaS) that provides remote access to software and its functions as a network-based service; a platform as a service (PaaS) that provides a computing platform that can simplify the process of creating and deploying software; and infrastructure as a service (IaaS) that provides IT infrastructure, such as servers, storage, and networking over the internet.

Important to a cloud computing environment is a mechanism for ensuring that devices accessing various services are registered to do so (e.g., for cloud connected devices with embedded processors). Each device has an identifier that can be provisioned and managed from the cloud. Using this identifier, the cloud system can determine those resources that the device is authorized to access. Typically, the identifier is in the form of a certificate, where the private part of the certificate key is securely stored in the device, while the public part is signed by the certificate authority. Enrollment includes securely obtaining an identifier of the device in the form of a digital certificate. The identifier may then be used to connect to the cloud service.

Existing enrollment processes provide only single step device authentication. Such single-step authentication does not allow for authenticating devices based on, for example, trusted manufacturers, production quotas of device manufacturers, different device types and device capabilities, and so forth. It is desirable to have such functionality in heterogeneous environments with many potential registrar devices (e.g., IoT devices).

Disclosure of Invention

According to a first aspect of the present invention there is provided a multi-phase method for registering a network device with a network service, the method comprising:

during a first phase, obtaining, by the network device, a first temporary digital certificate from a first network server using first information stored in the network device during manufacture of the network device;

during a second phase, obtaining, by the network device, one of a second temporary digital certificate or an e-token from a second network server using the first temporary digital certificate and second information stored in the network device during manufacture of the network device; and

during a third phase, obtaining, by the network device, a long-term digital certificate from a third network server using the one of a second temporary digital certificate or an e-token, wherein the network device is configured to communicate with the network service using the long-term digital certificate.

In one or more embodiments, the first stage comprises:

communicating with the first network server using a secure communication protocol;

transmitting a shared boot secret to the first network server, wherein the first information comprises the shared boot secret; and

receiving the first temporary digital certificate from the first network server in response to the first network server authenticating the shared boot secret.

In one or more embodiments, the connecting with the first network server further comprises:

establishing secure communications using the secure communication protocol using information in a registration Certificate Authority (CA) certificate, wherein the first information further includes the registration CA certificate.

In one or more embodiments, the second stage comprises:

communicating with the second network server using a secure communication protocol;

transmitting the first temporary digital certificate to the second network server;

transmitting the second information stored in the network device to the second network server;

receiving the second temporary digital certificate or etoken from the second network server in response to the second network server authenticating the first temporary digital certificate and the second information.

In one or more embodiments, the second information includes one or more of the following

A unique identifier of the device;

a unique identifier of a manufacturer of the device;

a unique identifier of a model of the device; and

a key generated by or securely programmed on the device, wherein the public portion of the key is accessible to the second network server.

In one or more embodiments, the second network server authenticating the second information comprises:

comparing the second information with manufacturer-related information stored at the second network server;

providing the authentication in response to the second information complying with the manufacturer-related information.

In one or more embodiments, the comparing the second information to the manufacturer-related information stored at the second network server comprises:

associating the network device with a manufacturer of the network device, wherein the second information comprises a manufacturer identifier; and

determining whether the network device is within an allowed number of devices manufactured by the manufacturer of the network device.

In one or more embodiments, the comparing the second information to the manufacturer-related information stored at the second network server comprises:

associating the network device with a device type, wherein the second information comprises a device type identifier; and

determining whether the network device is within an allowed number of devices of the device type.

In one or more embodiments, the comparing the second information to the manufacturer-related information stored at the second network server comprises:

associating the network device with a manufacturer of the network device, wherein the second information comprises a security key associated with the manufacturer; and

determining whether the network device is a device from the manufacturer by using a public portion of the security key stored at the second network server.

In one or more embodiments, the second network server authenticating the second information comprises:

comparing the second information with user-related information stored at the second network server; and

providing the authentication in response to the second information complying with the user-related information.

In one or more embodiments, the comparing the second information to the user-related information stored at the second network server comprises:

associating the network device with a user of the network device, wherein the second information comprises a user identifier; and

determining whether the network device is within an allowed number of devices registered by the user of the network device.

In one or more embodiments, the third stage includes:

communicating with the third network server using a secure communication protocol;

transmitting the second temporary digital certificate or e-token to the third network server;

receiving the long-term digital certificate from the third network server in response to the third network server authenticating the second temporary digital certificate or e-token.

In one or more embodiments, the long-term digital certificate is provided to the third network server by a certificate authority associated with a network service provider to enable the network device to securely communicate with the network service.

In one or more embodiments, the method further comprises:

securely communicating with the network service using the long-term digital certificate.

According to a second aspect of the present invention, there is provided a method for registering a network device with a network service, the method comprising:

obtaining, by the network device, a first temporary digital certificate or e-token from a first network server using a second digital certificate and information stored in the network device during manufacture of the network device; and

obtaining, by the network device, a long-term digital certificate from a second network server using the first temporary digital certificate or an e-token, wherein the network device is configured to communicate with the network service using the long-term digital certificate.

In one or more embodiments, the obtaining the first temporary digital certificate or e-token comprises:

communicating with the first network server using a secure communication protocol;

transmitting the second temporary digital certificate to the first network server;

transmitting the information stored in the network device to the first network server; and

receiving the first temporary digital certificate or etoken from the first network server in response to the first network server authenticating the second temporary digital certificate and the information.

In one or more embodiments, the first network server authenticating the information comprises:

comparing the information with manufacturer-related information stored at the first network server; and

providing the authentication in response to the information conforming to the manufacturer-related information.

In one or more embodiments, the comparing the information to manufacturer-related information stored at the network server comprises:

associating the network device with a manufacturer of the network device, wherein the information comprises a manufacturer identifier; and

determining whether the network device is within an allowed number of devices manufactured by the manufacturer of the network device.

In one or more embodiments, the comparing the information to manufacturer-related information stored at the first network server comprises:

associating the network device with a device type, wherein the information comprises a device type identifier; and

determining whether the network device is within an allowed number of devices of the device type.

In one or more embodiments, the method further comprises:

obtaining, by the network device, the second temporary digital certificate from a third network server using boot information stored in the network device during manufacture of the network device.

These and other aspects of the invention are apparent from and will be elucidated with reference to the embodiments described hereinafter.

Drawings

Embodiments of the invention may be better understood by referring to the following drawings.

FIG. 1 is a simplified block diagram illustrating an example of an edge computing environment.

Figure 2 is a simplified block diagram illustrating an example of a certificate authority trust infrastructure suitable for use with embodiments of the present invention.

Fig. 3 is a simplified flow diagram illustrating the stages of a registration procedure provided by an embodiment of the present invention.

Fig. 4 is a simplified timing diagram illustrating details of a boot (bootstrapping) phase according to one embodiment of the invention.

Fig. 5 is a simplified timing diagram illustrating the details of the association, authentication and authorization phases according to one embodiment of the present invention.

Fig. 6 is a simplified timing diagram illustrating details of a registration phase according to one embodiment of the present invention.

Fig. 7 is a simplified block diagram illustrating components of an example IoT sensor node 700 that may incorporate embodiments of the present invention.

The use of the same reference symbols in different drawings indicates identical items unless otherwise noted. The drawings are not necessarily to scale.

Detailed Description

Embodiments of the present invention provide a mechanism for a device to securely register with a cloud platform. This serves as a basis for securing the security of devices that can be provisioned and managed from the cloud, such as edge computing and internet of things gateways. A Public Key Infrastructure (PKI) mechanism is provided for registration that is divided into three phases. The first and second stages of the secure enrollment process authenticate the device and ensure that the device complies with the device manufacturer's manufacturing limitations. The third phase of the secure enrollment process provides the device with long-term operational credentials for access by cloud resources.

As discussed above, conventional cloud computing provides a shared pool of configurable computing resources that can be provisioned and published for those nodes that access those resources. However, conventional cloud computing relies on a large amount of data being transferred from and to the access node. This can be overly time consuming and network-capable resources. Thus, edge computing has been introduced as a way to reduce traffic flow from devices on the edge of the cloud (e.g., an industrial network incorporating internet of things (IoT) devices) and to provide near real-time local data analytics while only passing data that needs to be passed to the cloud resources. In one example of a typical edge computing scenario, IoT devices communicate data collected by those devices to a local edge computing device that includes computing devices, storage devices, and network resources in a small form factor. The data is processed at the edge, responded to in an appropriate manner, and only data that needs to be transferred to the cloud-based resources is transferred.

FIG. 1 is a simplified block diagram illustrating an example of an edge computing environment. Network node 110 and edge service node 120 all function in an edge network environment. Such environments may be local area networks, enterprise local area networks, personal area networks, and so on. The edge network environment may be coupled to a wide area network 140 (e.g., the internet) through an edge gateway 130. Coupled to the edge network environment is a wide area network 140 is a cloud service 150. Nodes in the edge network environment may access these networks through network protocols known in the art.

The network nodes 110 may be, for example, internet of things (IoT) type devices that may provide distributed sensor and other device functionality. These devices may be configured to collect data relating to their environment. Network node 110 or edge service node 120 may provide computing resources to analyze and respond to data collected by network node 110, with data being generated closer to the network node 110 than to cloud service 150. This allows for a faster response to such data, which is critical to the environment in which delay sensitive information is collected (e.g., financial services, manufacturing, and medicine). This also allows data to be filtered locally to provide only important or necessary data to the cloud service 150. This may occur, for example, in environments where large amounts of data are generated, but most of those data is not of concern. In addition to using cloud services 150 for centralized computing, storage, and other network applications, edge computing nodes, such as network nodes 110 and edge service nodes 120, may also utilize cloud services for firmware and software installation, updates, and configuration.

To restrict access to cloud service resources, a device authentication mechanism is used. One method of authenticating a device is to use certificate-based authentication. Digital certificates (also known as public key certificates or identification certificates) are used to identify devices before access to resources, networks, applications, etc. is allowed. A secure sockets layer/transport layer security (SSL/TLS) certificate is a digital certificate that combines the ownership details of a server with a cryptographic key. The key is used in SSL/TLS protocol communications to initiate a secure session between the client and the server hosting the certificate. In order for a client to trust an SSL/TLS certificate and establish an SSL/TLS session without a security alert, the SSL/TLS certificate should include the domain name of the server using it and should be issued by a trusted Certificate Authority (CA). Digital certificates are issued by a Certificate Authority (CA), a trusted network node that pre-authorizes the issuance of SSL/TLS certificates.

The CA may check the identity of the requesting client before issuing the digital certificate. These checks relate to the category and type of certificate requested. Initially, the device may trust the CA by having a root certificate pre-installed in the device. The CA uses the root certificate to authorize issuing certificates to the devices. The CA will receive the certificate request, validate the application, issue the certificate (e.g., SSL/TLS certificate), and disclose the validity status of the issued certificate in progress so that the certificate-dependent server knows that the certificate is still valid.

Figure 2 is a simplified block diagram illustrating an example of a certificate authority trust infrastructure suitable for use with embodiments of the present invention. Each certificate authority controls trusted access to a set of servers and services in the cloud. Embodiments of the present invention control enrollment into a cloud service by having two separate trust zones, enrollment and operations, where each trust zone is governed by a separate certificate authority. As illustrated in fig. 1, the cloud service 150 is in an operational trust zone 210, with secure access to the operational trust zone 210 controlled by an operational CA 220. The registration CA 270 controls secure access to the registration trust zone 260. As illustrated, the registration trust zone 260 includes a boot secure transport registration (EST) server 230, an association, authentication, authorization server 240, and a registration EST server 250. The function of each of these registration trust zone servers will be discussed in more detail below.

Embodiments of the present invention provide enhanced security for operating servers by using separate registration and operational trust zones. Further, embodiments define a three-phase enrollment authentication that provides a high level of security by limiting the distribution of security code while providing flexibility to devices with different architectures and capabilities.

Fig. 3 is a simplified flow diagram illustrating the stages of a registration procedure provided by an embodiment of the present invention. Phase 1 is a bootstrap phase 310 that uses the pre-shared secret and the enrollment server root CA certificate to obtain a temporary bootstrap certificate from the bootstrap EST (B-EST) server 230. The pre-shared secret and the enrollment server root CA certificate may be provided to the device manufacturer and installed in the device during manufacture.

Phase 2 is an association, authentication and authorization phase (AAA)320 that uses the boot credentials provided to the device in phase 1 to establish a secure connection with the AAA server 240. During this stage, the device may be authenticated using device-specific parameters, such as manufacturer user ID, OEM user ID, device serial number, and so forth. If the device authentication is successful, a temporary authorization token may be issued to the device for other authentication.

Phase 3 is a registration phase 330 that uses a temporary authorization token to establish a secure connection with a registration EST (E-EST) server 250. The E-EST server will perform the final authorization task and issue long-term operating credentials that will allow the device to access services in the operating trust zone 210. As illustrated, there may be some devices that are securely manufactured and configured to skip phase 1 and phase 2, and thus interact directly with phase 3 to gain access to the operational trust zone. Finally, after completing the registration phase, the device may enter an operational phase 340 to access cloud services 150 serviced by the operational trust zone 210.

Fig. 4 to 6 provide details regarding the communication exchange in the three registration phases according to an embodiment of the present invention.

FIG. 4 is a simplified timing diagram illustrating details of the boot phase 310 according to one embodiment of the invention. This figure illustrates the communication between a client device (e.g., network node 110 or edge service node 120) and a B-EST server (e.g., B-EST server 230) during which the client device connects to the B-EST server and obtains a bootstrap certificate for phase 2. Initially, the client device connects with the B-EST server using a secure communication protocol, such as TLS/SSL (410). The information necessary for the client device to connect with the B-EST server is programmed into the client device during the secure manufacturing process. After connection, the client device may authenticate the connection to the correct server using the enrollment CA certificate programmed into the client device during manufacture. The enrollment CA certificate is used only for the boot phase and is the only CA certificate available to the manufacturer of the client device.

In one embodiment, the client device may proceed with authentication of the B-EST server by providing a Shared Boot Secret (SBS) to the B-EST (420). The SBS is also programmed into the client device during the secure manufacturing process. SBS is one of several mechanisms used to authenticate a client device during boot. Depending on the architecture of the client device, the security token may also be used for authentication. Once the information is provided from the SBS to the B-EST server, the B-EST server may authenticate the client device (430). Once the client device authenticates, the B-EST server may provide the client device with a temporary boot credential (440) that is stored by the client device for use in the next stage (450). The boot certificate may be temporary to avoid problems associated with manipulating and decrypting the boot certificate to enter subsequent stages of the enrollment process.

Phase 1 establishes a secure registration process in a CA separate from the operating CA and thus helps to circumvent attacks (e.g., man-in-the-middle attacks and denial-of-service attacks) on the operating server. At the end of phase 1, regardless of whether it is an authentication mechanism (e.g., SBS or token), all client devices will be at the same level of readiness of phase 2, as all authenticated client devices will receive the bootstrap credentials. Although the authentication mechanism of phase 1 is inherently weak, it is difficult for an attacker to actually harm the operating system, as the attacker also needs to solve phase 2 and phase 3.

Fig. 5 is a simplified timing diagram illustrating the details of the association, authentication and authorization phase 320 according to one embodiment of the present invention. This figure illustrates communication between a client device (e.g., network node 110 or edge service node 120) and an AAA server (e.g., AAA server 240) during which the client device connects to the AAA server and obtains an enrollment token for phase 3. Initially, the client device connects with the AAA server using a secure communication protocol, such as TLS/SSL or HTTPS (510). Communication security may be secured using an enrollment CA certificate programmed into the device during manufacture. The identification of the appropriate AAA server may be provided during phase 1 of the registration process or the identification may be programmed into the device during manufacture.

Once connected, the client device may provide the bootstrap certificate obtained in phase 1 to continue authentication of the device by the AAA server (520). All devices that successfully complete phase 1 will have the appropriate boot credentials to provide to the AAA server. Further, the client device may provide device-specific information to the AAA server for additional authentication. The device specific information may include, for example, a device UID, a manufacturer identification, a serial number, and other manufacturing information used to identify the specific device. The AAA server performs initial authentication using the bootstrap certificate (530). The bootstrap certificate determines that the client device is authorized to communicate with the AAA server. The AAA server may then use the device specific information provided by the client device to determine whether the client device is authorized for further registration (540). For example, the AAA server may have information such as the total number of devices from a particular manufacturer that are allowed to communicate with the operations server. If the client device information determines that the device is not within the number of devices, the AAA server may refuse to provide a security token to proceed with the next authorization step. Similarly, the client device manufacturer may program security information (e.g., a manufacturing key or additional private key) into the client device at manufacture, which is authenticated by the AAA server during phase 2. Security information may be provided by the manufacturer to the AAA server to perform these checks. The AAA server may deny the authentication device if the client device does not provide the correct security information. The type of authorization performed by the AAA server is not limited to the above scenario and may be flexibly designed to provide as high a level of authentication as is required by the operating service provider or the client device manufacturer for the application.

Once the client device authentication is successful, the AAA server may provide the client device with a provisional enrollment e-token or certificate (550) that is stored by the client device for use in the next stage (560). Like the credential provided in phase 1, the enrolment e-token of phase 2 is temporary, in order to avoid problems associated with manipulating and decrypting the enrolment e-token to enter subsequent phases of the enrolment process. The AAA server may maintain a mapping table containing a mapping of all valid client device IDs to e-tokens, as well as the expiration times of the e-tokens. The E-EST server may use the table in phase 3 to authenticate the device in phase 3.

Phase 2 ends the vendor specific authentication and authorization part of the enrollment process. Once completed, the already authorized devices are all ready to proceed to phase 3, where long-term operating certificates are issued. The secure communication protocol used in phase 2 may be selected to flexibly allow different client device vendors to present the security token in different ways. For example, HTTPS may be used to allow multiple challenge-response cycles to occur between a client device and an AAA server. In addition, the results of the authentication process can be used to direct devices of different manufacturers to different E-EST servers in phase 3, allowing different operating certificates to be issued.

Fig. 6 is a simplified timing diagram illustrating the details of the register EST phase 330 according to one embodiment of the present invention. This figure illustrates the communication between a client device (e.g., network node 110 or edge service node 120) and a registered EST server (e.g., E-EST server 250), during which the client device connects to the E-EST server and obtains an operational CA certificate for accessing cloud services 150 in the operational area 210. Initially, a client device connects with an E-EST server using a secure communication protocol, such as TLS/SSL or HTTPS (610). Communication security may be protected using an enrollment CA certificate programmed into the device during manufacture or a bootstrap certificate received in phase 1. The identification of the appropriate E-EST server may be provided during phase 2 of the enrollment process (e.g., as part of E-token passing), or the identification may be programmed into the device during manufacture.

Once secure communication is established between the client device and the E-EST server, the client device provides the enrollment E-token received by the client in phase 2, along with any other credentials required by the E-EST server (620). It should be noted that in some cases where a securely manufactured client device is accessing the enrollment process, those devices may be configured with or generate their own enrollment e-token, or may be pre-programmed with an enrollment e-token. In these cases, those secure client devices may access the E-EST server without going through stages 1 or 2 and provide the E-EST server with the E-token generated or stored by the secure client.

After receiving the registration E-token information, as well as any other information needed by the E-EST server, the E-EST server authenticates the client device (630). If the information provided by the client device is not explicitly authenticated (e.g., the enrollment E-token has expired), the E-EST server will not provide credentials to access the operating service. If the information is explicitly authenticated, the E-EST server may communicate with the operational CA to obtain long-term operational security certificates (640), which are then provided to the client device (650). The client device stores the operation security certificate and may generate a device-specific key associated with the operation CA to access the operation service 150 (660).

The three-phase registration process provided by embodiments of the present invention provides advantages over previous registration mechanisms. The three-phase registration process is more secure than previous registration mechanisms because only B-ESTCA certificates are assigned to manufacturers. The E-EST CA certificate is provided only by the securely manufactured device. Phase 1EST registration enhances the security of subsequent certificate exchanges in subsequent phases. Furthermore, three-phase registration has flexibility in that multiple devices and architectures may be provided with credentials that allow entry into subsequent phases. The authentication provided may be device type specific.

Fig. 7 is a simplified block diagram illustrating components of an example IoT sensor node 700 that may incorporate embodiments of the present invention. IoT sensor node 700 incorporates a Microcontroller (MCU)710 programmed to receive data from sensor module 720 and provide information from the data to other network nodes through wireless connection module 740. For example, MCU 710 may be an 8-bit, 16-bit, or 32-bit MCU, where low to medium complexity nodes use 8-bit or 16-bit MCUs, while high complexity nodes use 32-bit MCUs. For example, the selection of the MCU type may depend on the data throughput requirements and the applied power constraints. The MCU may have a sensor interface, a voltage regulator, and an on-chip RF radio, or those devices may be external to the MCU.

Sensor module 720 may include one or more of a variety of sensor types, including, for example, smart sensors, RFID or near field communication, optical sensors, image sensors, environmental sensors, and so forth. A smart sensor is a sensor that includes data processing in the sensor. These may include, for example, environmental sensors that perform simple processing of the acquired environmental data or micro-electromechanical systems (MEMS) sensors with gyroscopes and accelerometers where integrated digital processing is done for sensor fusion calculations. The RFID or near field communication sensor may be configured to detect the presence of an item identified with an RFID or NFC tag. Optical sensors are used to detect the presence of light in visible or invisible wavelengths. The image sensor is a photosensitive sensor array (e.g., CCD) that converts an image into an electrical signal. The environmental sensor is configured to detect an environmental condition surrounding the sensor. Such information may include, for example, pressure, temperature, position, acceleration, motion, or orientation. The sensors in sensor module 720 may provide digital outputs that are read by MCU 710.

Further, the sensor module 720 may include an input for a system that provides an analog signal. In these cases, sensor module 720 may include an analog-to-digital converter (ADC), particularly when the application requires high speed or high precision conversion. Alternatively, in applications where an ADC is insufficient, the sensor module 720 may include an analog front end that includes an ADC and signal conditioning circuitry to provide a digital signal to the MCU.

In addition to the memory built in the MCU, the memory module 730 may also serve as a storage device for the MCU 710. For example, the memory module 730 may include a RAM or a flash memory or a removable memory to store programs or other data of the MCU.

The wireless connection module 740 is configured to provide communication between the IoT sensor node and other nodes (e.g., parent nodes or child nodes) in the network. As discussed above, embodiments of the present invention may be used in wireless mesh networks, such as those defined by IEEE 802.15.4. Such networks are typically used for low data rate, battery powered nodes distributed over a wide area. The wireless connection module may be configured to transmit and receive data with one or more other nodes in the network.

Power module 750 provides the appropriate voltages to MCU 510 and manages the battery to help increase battery life and ensure that the appropriate charging currents and voltages are applied. The power supply module 750 may also include low loss voltage regulators and boost/buck converters to help ensure that the IoT sensor node is operating at the proper voltage.

By now it should be appreciated that a multi-phase mechanism for registering network devices with network services has been provided. One embodiment of this mechanism includes: during a first phase, obtaining, by a network device, a first temporary digital certificate from a first network server using first information stored in the network device during manufacture of the network device; during a second phase, obtaining, by the network device, one of a second temporary digital certificate or an e-token from a second network server using the first temporary digital certificate and second information stored in the network device during manufacture of the network device; and during a third phase, obtaining, by the network device, the long-term digital certificate from the third network server using the one of the second temporary digital certificate or the e-token, wherein the network device is configured to communicate with the network service using the long-term digital certificate.

In one aspect of the above embodiment, the first stage comprises: communicating with a first network server using a secure communication protocol; transmitting the shared boot secret to a first network server, wherein the first information comprises the shared boot secret; and receiving a first temporary digital certificate from the first network server in response to the first network server authenticating the shared boot secret. In another aspect, connecting with the first network server further comprises establishing secure communications using a secure communications protocol using information in a Certificate Authority (CA) certificate, wherein the first information further comprises the CA certificate of enrollment.

In another aspect of the above embodiment, the second stage comprises: communicating with a second network server using a secure communication protocol; transmitting the first temporary digital certificate to a second network server; transmitting second information stored in the network device to a second network server; and receiving a second temporary digital certificate or e-token from the second network server in response to the second network server authenticating the first temporary digital certificate and the second information. In another aspect, the second information includes one or more of a unique identifier of the device, a unique identifier of the manufacturer of the device, a unique identifier of the model of the device, and a key generated by or securely programmed on the device, wherein the second network server has access to a public portion of the key. In another aspect, the second network server authenticating the second information comprises: the second information is compared to manufacturer-related information stored at the second network server, and the authentication is provided in response to the second information complying with the manufacturer-related information. In yet another aspect, comparing the second information with the manufacturer-related information stored at the second network server includes: associating the network device with a manufacturer of the network device, wherein the second information comprises a manufacturer identifier; and determining whether the network device is within an allowable number of devices manufactured by a manufacturer of the network device. In another aspect, comparing the second information with the manufacturer-related information stored at the second network server includes: associating the network device with a device type, wherein the second information comprises a device type identifier; and determining whether the network device is within an allowed number of devices of said device type. In another aspect, comparing the second information with the manufacturer-related information stored at the second network server includes: associating the network device with a manufacturer of the network device, wherein the second information comprises a security key associated with the manufacturer; and determining whether the network device is a manufacturer's device by using the public portion of the security key stored at the second network server.

In another aspect, the second network server authenticating the second information comprises: the second information is compared to user-related information stored at a second network server, and the authentication is provided in response to the second information complying with the user-related information. In another aspect, comparing the second information with user-related information stored at the second network server comprises: associating the network device with a user of the network device, wherein the second information comprises a user identifier; and determining whether the network device is within an allowed number of devices registered by a user of the network device.

In another aspect, the third stage includes: communicating with a third network server using a secure communication protocol; transmitting the second temporary digital certificate or the e-token to a third network server; and receiving the long-term digital certificate from the third network server in response to the third network server authenticating the second temporary digital certificate or the e-token. In another aspect, the long-term digital certificate is provided to a third network server by a certificate authority associated with the network service provider to enable the network device to securely communicate with the network service.

In another aspect, the above embodiments further comprise using the long-term digital certificate to securely communicate with the network service.

Another embodiment provides a method for registering a network device with a network service. The method comprises the following steps: obtaining, by the network device, a first temporary digital certificate or e-token from a first network server using a second digital certificate and information stored in the network device during manufacture of the network device; and obtaining, by the network device, the long-term digital certificate from the second network server using the first temporary digital certificate or the e-token, wherein the network device is configured to communicate with the network service using the long-term digital certificate.

In one aspect of the above embodiment, obtaining the first temporary digital certificate or e-token comprises: communicating with a first network server using a secure communication protocol; transmitting the second temporary digital certificate to the first network server; transmitting information stored in the network device to the first network server; and receiving the first temporary digital certificate or the e-token from the first network server in response to the first network server authenticating the second temporary digital certificate and the information. In another aspect, the first network server authentication information includes: the information is compared to manufacturer-related information stored at the first network server, and the authentication is provided in response to the information complying with the manufacturer-related information. In yet another aspect, comparing the information with the manufacturer-related information stored at the network server includes: associating the network device with a manufacturer of the network device, wherein the information comprises a manufacturer identifier; and determining whether the network device is within an allowable number of devices manufactured by a manufacturer of the network device. In another aspect, comparing the information with the manufacturer-related information stored at the first network server includes: associating the network device with a device type, wherein the information comprises a device type identifier; and determining whether the network device is within an allowed number of devices of said device type. In another aspect, the first network server authentication information includes: the information is compared with user-related information stored at the first network server, and the authentication is provided in response to the information complying with the user-related information.

In another aspect of the above embodiment, the method further comprises obtaining, by the network device, the second temporary digital certificate from a third network server using boot information stored in the network device during manufacture of the network device.

Because the apparatus implementing the present invention is, for the most part, composed of electronic components and circuits known to those skilled in the art, circuit details will not be set forth in any greater extent than that considered necessary as illustrated above, for the understanding and appreciation of the underlying concepts of the present invention and in order not to obfuscate or distract from the teachings of the present invention.

The term "program", as used herein, is defined as a sequence of instructions designed for execution on a computer system. The program or computer program may include a subroutine, a function, a procedure, an object method, an object implementation, an executable application, an applet, a servlet, a source code, an object code, a shared library/dynamic library and/or other sequence of instructions designed for execution on a computer system.

Some of the above embodiments may be implemented using a variety of different information processing systems, where appropriate. For example, although fig. 7 and the discussion thereof describe an exemplary network node architecture, such an exemplary architecture is presented merely to provide a useful reference in discussing aspects of the invention. The description of the architecture has been simplified for purposes of discussion, and it is just one of many different types of suitable architectures that may be used in accordance with the invention. Those skilled in the art will recognize that the boundaries between logic blocks are merely illustrative and that alternative embodiments may merge logic blocks or circuit elements or impose an alternate decomposition of functionality upon various logic blocks or circuit elements.

Thus, it is to be understood that the architectures depicted herein are merely exemplary, and that in fact many other architectures can be implemented which achieve the same functionality. In an abstract, but still definite sense, any arrangement of components to achieve the same functionality is actually "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being "operably connected," or "operably coupled," to each other to achieve the desired functionality.

Furthermore, those skilled in the art will recognize that boundaries between the functionality of the above described operations merely illustrative. The functionality of multiple operations may be combined into a single operation, and/or the functionality of a single operation may be distributed in additional operations. Moreover, alternative embodiments may include multiple instances of the operations, and the order of the operations may be altered in various other embodiments.

All or some of the software described herein may be receiving elements of system 710, e.g., a non-transitory computer-readable medium, such as memory 730 or other medium on other computer systems. Such non-transitory computer-readable media may be permanently, removably or remotely coupled to the system. Non-transitory computer-readable media may include, for example but not limited to, any number of: magnetic storage media including magnetic disk and tape storage media; optical storage media such as optical disk media (e.g., CD-ROM, CD-R, etc.) and digital video disk storage media; non-volatile memory storage media including semiconductor-based memory units such as flash memory, EEPROM, EPROM, ROM; a ferromagnetic digital memory; an MRAM; volatile storage media including registers, buffers or cache memory, main memory, RAM, and the like.

In some embodiments, the edge network may include computer systems as network nodes, such as personal computer systems. Other embodiments may include different types of computer systems. Computer systems are information handling systems that may be designed to enable one or more users to obtain independent computing capabilities. The computer system may take many forms, including but not limited to: mainframes, minicomputers, servers, workstations, personal computers, notepads, personal digital assistants, electronic games, automotive and embedded systems, cellular telephones, and various other wireless devices. A typical computer system includes at least one processing unit, associated memory, and a plurality of input/output (I/O) devices.

Although the invention is described herein with reference to specific embodiments, various modifications and changes can be made without departing from the scope of the present invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present invention. Any advantages, or solutions to problems that are described herein with regard to specific embodiments are not intended to be construed as a critical, required, or essential feature or element of any or all the claims.

As used herein, the term "coupled" is not intended to be limited to a direct coupling or a mechanical coupling.

Furthermore, the terms "a" or "an," as used herein, are defined as one or more than one. Furthermore, the use of introductory phrases such as "at least one" and "one or more" in the claims should not be construed to imply that the introduction of another claim element by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an". The same holds true for the use of definite articles.

Unless otherwise stated, terms such as "first" and "second" are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other priority of such elements.