KR20160071456A - Method for assigning an agent device from a first device registry to a second device registry - Google Patents

Abstract

The agent device 4 is registered in the first device registry maintained by the first registry device 8 for authenticating the agent devices 4 to communicate with the application providing devices. The agent device 4 may be assigned to a second device registry maintained by the second registry device 80. [ The allocation method includes the step 250 of the first registry device 8 receiving a device allocation request from the requestor device. In response to the device allocation request, the first registry device 8 checks whether the agent device 4 is allowed to be assigned to the second device registry 80, and if so, the agent device 4, (290) the second authentication information for authenticating the identity of the agent device (4) to the second registry device (80) which registers the second authentication information in the second device registry.

Description

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method for allocating an agent device from a first device registry to a second device registry,

The present invention relates to the field of data processing. More specifically, the present invention relates to a method of assigning an agent device from a first device registry to a second device registry.

Within a home, other building or outdoor environment, there are an ever-increasing number of devices with processing and communication capabilities that allow them to interact with other processing devices. The daily objects and relatively small processing devices may be connected to each other and to the central platform as part of the "Internet of Things ". For example, a sprinkler system in the home can collect information from various humidity sensors and control the operation of the sprinkler based on humidity information. The healthcare provider can also use a wireless sensor (e.g., a heart rate monitor or a sensor to monitor whether the patient is taking the prescribed medication) to track the health of the patient at home.

Thus, in various applications, there may be a central application providing device that interacts with one or more agent devices, and one or more agent devices provide data to the application providing device and / or are controlled by the application providing device. Agent devices can vary considerably in terms of complexity, processing resources, hardware, and purpose. It may be important to provide trust between the agent device and the application providing device so that the application provider can trust the validity of the data received from the agent device and allow the agent device to trust any command received from the application providing device. However, since many agent devices in the things Internet have little processing power, it can be difficult to provide resources to the agent device to establish a trusted relationship with the application providing device, and can significantly increase the cost of the agent device. The rapid and extensive deployment of these agent devices means that there is a desire to make installation as fast and efficient as possible.

Viewed from a first aspect, the present invention provides an agent device registered in a first device registry maintained by a first registry device for authenticating agent devices for communicating with at least one first application provision device, To a second device registry maintained by a second registry device for authenticating agent devices for communicating with a second application providing device, wherein the first device registry is configured to authenticate the identity of the agent device The method comprising the steps < RTI ID = 0.0 > of: < / RTI &

(a) receiving a device allocation request from a requestor device, the first registry device requesting that an agent device be assigned to a second device registry;

(b) in response to the device allocation request, checking whether the first registry device is allowed to be assigned to the second device registry in response to the device allocation request from the requestor device;

(c) if the agent device is allowed to be assigned to the second device registry, sending the second authentication information for authenticating the identity of the agent device to the second registry device; And

(d) the second registry device registers second authentication information for the agent device in the second device registry.

The registry device may be provided for managing a trusted relationship between the agent device and the application providing device. For example, the registry device may store authentication information for the agent device and may use the authentication information to manage the authentication of the agent device. The registry may also perform tasks such as, for example, providing an application key for establishing trusted communications between the agent device and the application providing device. Using a registry device in this way may provide several advantages, such as allowing an agent device and an application providing device provided by different manufacturers or providers to trust each other and not be constrained to communicate with devices from the same manufacturer . In addition, using the registry to coordinate authentication and establishing trusted communications can simplify the resources of the agent device because the agent device does not need to be responsible for establishing trust with the application providing device.

The present technique recognizes that it may be useful to provide more than one device registry maintained by different registry devices. For example, a private registry is operated by an organization such as a government to enable secure management of communication with the agent devices independently of other agent devices registered in the public registry. Different application provision devices may be similarly associated with different registries. It may be useful to allow a device registered in one device registry to be assigned to a second device registry in order to extend, modify or constrain the range of application providers with which a particular sensor can communicate. However, in order to maintain the trust of the agent device, it may be important to do this in a secure state. The device allocation request is transmitted to the first registry device that currently holds the registration of the agent device so as to trigger the first registry device to check whether the agent device is allowed to be assigned to the second device registry in response to the device allocation request , A security allocation procedure can be achieved.

The first registry device may maintain first authentication information for authenticating the identity of the agent device. If the device is assigned to the second device registry, the device sends the second authentication information to the second registry device for registration in the device registry. In some examples, the second authentication information is the same as the first authentication information, allowing the second registry to receive exactly the same information that was originally registered in the first registry. For example, the agent device may send its original authentication information to the second registry simply because it may not have any ability to generate new authentication information. In this case, following the allocation, the agent device may be registered in both the first registry and the second registry, for example, and authenticated by any registry using the same authentication information. This may be useful for extending the range of application providing devices from which the agent device may enter trusted communication.

In another example, the second authentication information may be different from the first authentication information. For example, the agent device may have an authentication information generation circuit for generating second authentication information, so that new authentication information is generated upon assignment to the second registry. For example, the second authentication information may be a new key for encrypting a message from an agent device to verify its identity. This allows the agent device to receive a new trusted cryptographic identity and once it is transferred to the second registry, it can no longer be authenticated by the first registry.

After determining that the agent device is allowed to be assigned to the second device registry, the first registry device deletes the first authentication information for the agent device from the first device registry so that the agent device is no longer And can not be authenticated. Alternatively, the agent device may regenerate the authentication information and may no longer hold any authentication information corresponding to the first authentication information. In this case, it may not be necessary for the first registry device to delete the first authentication information because the agent device can no longer be authenticated using the first authentication information anyway.

In one example, the first authentication information may include the same symmetric key as the corresponding key held by the agent device, and the second authentication information may similarly include a symmetric key corresponding to a corresponding key in the agent device (The second authentication information may be the same as or different from the first authentication information as discussed above). However, additional security can be achieved by embodiments where the agent device holds the private key and the first or second authentication information includes a public key corresponding to the private key held by the agent device. In these embodiments, the asymmetric nature of the keys means that only the agent device can access the private key and the public key maintained by the registry does not expose the private key maintained by the agent device, even if exposed to other devices .

For example, the agent device can originally hold the first private key and the corresponding first public key can be registered in the first registry. When assigned to the second registry, the agent device generates a new key pair including the second private key and the second public key, maintains the second private key, and registers the second public key in the second registry 2 Can be transferred to the registry device. If the agent device deletes the first private key after sending the second authentication information to the second registry device, after the assignment, the corresponding first private key, which can be verified using the first public key, is no longer present The first public key held by the first registry device becomes useless. In this case, from a security point of view, although it is not essential that the first registry device delete the first public key from the first device registry, it may still delete the registry entry for the agent device to save storage capacity of the first registry device have.

When transmitting the second public key to the second registry device, the agent device can transmit a digital certificate including the public key and the second registry device can sign the digital certificate. Thus, the second registry device may act effectively as a certificate authority for the digital certificate, including a public key that verifies whether the public key is actually from the agent device. For example, an X.509 certificate can be used as a digital certificate.

If the first registry device determines that the agent device is allowed to be assigned to the second device registry, there may be various ways that the agent device can be triggered to send the second authentication information to the second registry device. The first registry device informs the device itself that it is assigned to a different registry, and the device can then respond by sending the second authentication information to the second registry device. In addition, the first registry device may notify the second device registry or another device, such as the requestor device that issued the device allocation request, that the allocation has been granted, and the device may then send the agent device You can trigger.

The creation or deletion of authentication information by either the agent device or the first registry device may be performed as an atomic operation. This means that it is not possible to perform atomic operations in part, as the creation or deletion of a key must proceed so that its operation as a whole is either completely successful or completely unsuccessful. This is similar to an atomic transaction in a database that succeeds or fails but can not be partially successful. By performing regeneration of key information or other authentication information as an atomic operation, this ensures that the agent device will always have the appropriate authentication information to verify its identity with the first registry or the second registry, It is not possible that there is no authentication information that could lead to the loss of the ability to verify the identity or that it ends with invalid authentication information. Atomic operations can be performed, for example, by taking a backup of the original authentication information before the creation or deletion of key information begins, and then restoring the backup if any problems occur before the atomic operation is completed.

In some cases, the requestor device making the device allocation request may be a third party device separate from the first registry and the second registry. For example, in the context of a smartly connected city having its own private registry as a second device registry, another device in the city, such as a platform operated by the city manager, requests the device to be assigned to the second registry Quot; < / RTI >

In another example, the requested device includes a second registry device itself, and the second registry device makes a device allocation request in the first registry device to request that the device be assigned to a second registry held by the same device, .

The first registry device may check whether the agent device is allowed to be assigned to the second device registry in different manners. In one example, the first registry device can authenticate the requestor device to verify that the requestor device is trusted and is allowed to request the allocation of the agent device to another registry. For example, the first registry device may exchange a message with the requested device to verify the identity of the requestor device. Alternatively, the first registry device may have already verified a requested device and simply check whether the requested device has already been authenticated. Therefore, it is not necessary to actually perform the authentication when receiving the device allocation request.

Also, not all agent devices may support allocation to different registries. For example, for security reasons, some agent devices may be restricted to being registered in a single registry. In addition, some agent devices do not support key generation and are not allowed to migrate to different registries, so that only one registry may have a certificate to authenticate the agent device. Other agent devices may still be allowed to be assigned to different registries by providing the same authentication information to both registries, even though security is less important and thus may not have key generation capability. Thus, checking that the agent device is allowed to be assigned to the second device registry may also include checking whether the agent device actually supports allocation to the second device registry. For example, the first registry may include metadata for each trusted device indicating whether the device is allowed to be assigned to a different registry.

Checking may also include other actions. For example, if a plurality of requests for the same agent device corresponding to different target device registries are received, there may be some priority checks associated with each target registry to determine which registry should be assigned to the device . Checking may also include a mix of all of the different types of checks described above.

The agent device can store the address of the registry device currently holding the registration. The address may be any information that allows the agent device to contact the registry device, such as, for example, a uniform resource locator (URL), an internet protocol address (IP) address, During the allocation, the first registry device, the second registry device, or the requestor device may send the address of the second registry device to the agent device, and the agent device may subsequently send the address of the stored registry You can update your copy. Thus, the assignment process may include updating the contact information to contact the registry.

Following the assignment of the agent device to the second device registry, it may be desirable later to return the registration of the agent device to the first device registry. Thus, the first registry device may receive a reset request (from the second registry device or another requesting device). In response to the reset request, the first registry device can check whether the agent device is allowed to be reassigned to the first device registry, and if so, the agent device registers the third authentication information in the first device registry To the first registry device. ≪ RTI ID = 0.0 > The third authentication information may be the same or newly generated authentication information as the first or second authentication information. Thus, if the second device registry no longer wishes to register the device, it can return to its original registry.

The assignment of the agent device from the first device registry to the second device registry may be performed without any intervention from the user of the agent device. There is no need for the agent device to be provided with any user interface for coordinating the allocation of the device to the second registry. Alternatively, the first registry device, the second registry device and / or the requestor device may control the transmission of the second authentication information from the agent device without user involvement. The user does not even need to know that their device is being transferred to a different registry.

Viewed from another aspect, the present invention provides a first registry device for authenticating agent devices for communicating with one or more application providing devices, the registry device comprising:

A first device registry of agent devices, the first device registry comprising authentication information for authenticating the identity of the agent devices;

A communication circuit configured to receive from the requestor device a device assignment request requesting that an explicit agent device registered in the first device registry be assigned to a second device registry of agent devices maintained by the second registry device; And

The method comprising: checking whether an explicit agent device is allowed to be assigned to a second device registry in response to a device assignment request; if the specified agent device is allowed to be assigned to a second device registry, And to instruct the at least one of the registry devices that the specified agent device can be assigned to the second device registry.

Thus, a first registry device currently holding a registration for a particular agent device receives the device allocation request, checks if the device is allowed to be assigned to the second device registry, and then executes the assignment, The requestor device, and the second registry device.

Viewed from a further aspect, the invention provides a first registry device for authenticating agent devices for communicating with one or more application providing devices, the registry device comprising:

Storage means for storing a first device registry of agent devices, the first device registry including authentication information for authenticating the identity of the agent devices;

Communication means for receiving a device assignment request from a requestor device requesting that an explicit agent device registered in a first device registry be assigned to a second device registry of agent devices maintained by a second registry device;

The method comprising: checking whether an explicit agent device is allowed to be assigned to a second device registry in response to a device assignment request; if the specified agent device is allowed to be assigned to a second device registry, Processing means for controlling the communication means to instruct at least one of the registry devices that the specified agent device can be assigned to the second device registry.

In yet another aspect, the invention provides a method for maintaining a first device registry of agent devices for communicating with one or more application providing devices, wherein the first registry device stores the identity of the agent devices Authentication information for authentication, the method comprising the steps of:

Receiving, from the requestor device, a device assignment request requesting that an explicit agent device registered in the first device registry be assigned to a second device registry of agent devices maintained by the second registry device;

Checking whether the specified agent device is allowed to be assigned to the second device registry in response to the device allocation request; And

Indicating that the specified agent device can be assigned to the second device registry if at least one of the specified agent device, the requestor device, and the second registry device is allowed to be assigned to the second device registry if the specified agent device is allowed to be assigned to the second device registry.

Viewed from yet another aspect, the present invention provides a first registry device for authenticating agent devices for communicating with one or more application providing devices, the registry device comprising:

A first device registry of agent devices, the first device registry comprising authentication information for authenticating the identity of the agent devices;

A request to allocate a device to a second registry device to maintain a second device registry of agent devices - an allocation request to request an explicit agent device registered in a second device registry to be assigned to a first device registry; Circuit; And

And to register authentication information received from an explicit agent device for authenticating the identity of the specified agent device in the first device registry.

Thus, a registry device that is not currently maintaining a registration for an agent device may request that the agent device be transferred to its own registry. When the authentication information is received from the agent device, it is registered in the device registry for future authentication of the agent device.

Viewed from another aspect, the present invention provides a first registry device for authenticating agent devices for communicating with one or more application providing devices, the registry device comprising:

Storage means for storing a first device registry of agent devices, the first device registry including authentication information for authenticating the identity of the agent devices;

A request to allocate a device to a second registry device for maintaining a second device registry of agent devices, the request to allocate - the request for an explicit agent device registered in a second device registry to be assigned to a first device registry, Circuit; And

Processing means for registering, in a first device registry, authentication information received from an explicit agent device for authenticating the identity of the specified agent device.

From another aspect, the invention provides a method for maintaining a first device registry of agent devices for a registry device to communicate with one or more application providing devices, wherein the first device registry authenticates the identity of the agent devices The method comprising the steps of:

Transmitting a device allocation request-allocation request to a second registry device for maintaining a second device registry of the agent devices, wherein the specified agent device registered in the second device registry is requested to be assigned to the first device registry;

Receiving authentication information from an explicit agent device; And

Registering the authentication information received from the specified agent device in the first device registry.

Viewed from a further aspect, the invention provides an agent device for communicating with one or more application providing devices, the agent device comprising:

A processing circuit configured to perform authentication with a first registry device based on first authentication information registered for an agent device in a first device registry maintained by a first registry device;

An authentication information generation circuit configured to generate second authentication information for authenticating an identity of the agent device in response to a device assignment request to assign an agent device to a second device registry of agent devices maintained by the second registry device; And

And to transmit the second authentication information generated by the authentication information generation circuit to the second registry device to register in the second device registry.

Upon receiving a device allocation request (which may come from a first registry device, a second registry device, or another device, such as the requestor device described above), the agent device sends a trigger to generate second authentication information for authenticating its identity do. Then, the second authentication information is transmitted to the second registry device to which the device is to be assigned.

Viewed from another aspect, the present invention provides an agent device for communicating with one or more application providing devices, the agent device comprising:

Processing means for performing authentication with a first registry device based on first authentication information registered for an agent device in a first device registry maintained by a first registry device;

An authentication information generating means for generating second authentication information for authenticating the identity of the agent device in response to a device assignment request for assigning the agent device to a second device registry of agent devices maintained by the second registry device; And

And communication means for transmitting the second authentication information generated by the authentication information generating means to the second registry device for registering in the second device registry.

Viewed from a further aspect, the present invention provides a method for an agent device to communicate with one or more application providing devices, the method comprising the steps of:

Performing authentication with the first registry device based on the first authentication information registered for the agent device in the first device registry maintained by the first registry device;

Receiving a device allocation request to assign an agent device to a second device registry of agent devices maintained by a second registry device;

In response to the device assignment request, generating second authentication information for authenticating the identity of the agent device; And

And transmitting the second authentication information to the second registry device for registration in the second device registry.

Additional aspects, features and advantages of the present technology will become apparent from the following detailed description, which should be read in conjunction with the accompanying drawings.

1 schematically shows an example of a system including at least one registry device for establishing trusted communication between an agent device and an application providing device;
2 shows an example of a relationship between an agent device, an application provider, a device registry, and a consumer;
Figure 3 shows an exemplary timeline illustrating the progress of an agent device over a lifetime from manufacture to use in an application;
Figure 4 schematically shows an example of an agent device;
Figure 5 schematically illustrates an example of storage areas provided to an agent device for storing authentication information and other information for establishing communication with a registry device;
6 shows an example of an application providing apparatus;
Figure 7 shows an example of a registry device for maintaining a trusted device register;
Figure 8A shows an example of a registry entry for an agent device;
8B shows an example of an event record for an agent device;
9 is a graph showing the trade-off between cost of implementing security and security;
Figures 10, 11 and 12 illustrate three examples of authentication models for authenticating the identity of an agent device;
Figure 13 is a table comparing the different attributes of the authentication model shown in Figures 10-12;
Figure 14 illustrates a first exemplary method of establishing a trusted identity for an agent device;
Figure 15 illustrates a second exemplary method of establishing a trusted identity for an agent device;
Figure 16 illustrates a method for performing authentication between an agent device and a registry device and establishing encrypted communication between an agent device and an application providing device;
17 illustrates an example of a method of associating an agent device with a user and associating an agent device with a particular application;
18 shows an example of a method of assigning an agent device currently registered in a first registry to a second registry;
Figure 19 illustrates an example of a method for resetting the ownership of an agent device back to a first registry;
20-23 illustrate four examples of use cases of an agent device, a registry device, and an application providing device.

1 shows an example of a system 2 composed of a plurality of agent devices 4, an application providing device 6, and a registry device 8. The application providing device 6 may be any device that provides a cloud service and executes an application program using data collected from one or more agent devices 4 and / Lt; / RTI > devices. The agent device 4 may be any device that collects data for transmission to the application providing device 6 or is controlled by the application providing device 6. [ For example, the agent device 4 may be connected devices in the Internet of Things (IOT), such as wireless sensors and actuators. Agent device 4 may include a larger processing device, such as a tablet computer or a mobile phone, but often the agent device 4 may be a limited number of devices, such as sensors that collect sensed data and feedback it to the application A relatively small scale device that only performs a task set, or a relatively simple control unit that controls associated objects such as a sprinkler, a pool pump, or an air conditioning unit. The agent device 4 may communicate with other devices (such as the application providing device 6 and the registry device 8) using wired or wireless communication, which may be via an Internet connection. In the present application, the term "sensor" is sometimes used as an example of an agent device, but it will be appreciated that agent devices may also include devices capable of performing tasks other than detection.

The agent devices 4 and the application providing apparatus 6 communicate by encrypted communication. To help establish this encrypted communication, one or more registry devices 8 are provided for maintaining a trusted agent device registry that stores information about trusted agent devices 4. The registry 8 facilitates automated secure pairing of the agent device 4 with the application providing device 6 so that the application can be provided to the agent device 4 ) And ensures that the agent device (4) can trust the integrity and command integrity of the application (6). The registry 8 also simplifies the configuration of trusted communication between the agent device 4 and the application 6 so that the agent devices 4 do not need to know the specific details of the application with which they communicate, Thereby making it unnecessary for the user of the device 4 to perform a configuration operation for establishing communication with the application. Instead, when activated, the agent device 4 can simply contact the registry 8, and then the registry 8 can configure the agent device 4 and the application 6 to communicate with each other.

As shown in FIG. 1, a plurality of registry devices 8 may be provided, each of which is in contact with a different set of agent devices 4 and application providers 6. As shown in FIG. 1, it is possible that agent device A8 is registered in more than one registry. Similarly, the application providing apparatus 6 can communicate with a plurality of registries. It is also possible for most agent devices 4 to communicate with one application providing device 6, but it is also possible for the registry to configure the agent device 4 to communicate with a plurality of application providers (e.g., (See the agent device A2 of Fig.

The functions of the agent device 4 and the application providing device 6 may be significantly different for different applications. For example, the agent device 4 may collect weather data to be communicated to an application provider 6 that performs weather applications that perform a forecast based on the data collected by the agent device 4. In addition, some agent devices 4 may collect information about a user ' s fitness program, such as heart rate, ranged distance, etc., which may be fed back to the health monitoring application maintained by the application provider 6 . In another example, the domestic air conditioning system may include a central monitoring application 6 and multiple agent devices 4, such as a temperature sensor, a humidity sensor, a user configuration panel, and an air conditioning control unit, The application controls the operation of the air conditioning control unit based on the user's preferences set in the user configuration panel and the sensing of the sensors. There are many additional applications that can utilize the application providing device 6 and the one or more agent devices 4 in a similar manner. For example, there may be applications in home security, home or street lighting, utility provision, building automation, security maintenance, asset tracking and logistics. The registry 8 provides a common architecture for managing authentication and trust between the object Internet device and the application 6.

2 shows an example of the relationship between the agent device 4, the application provider 6, the registry 8, and the consumer 10. The consumer 10 has physical ownership of the agent device 4. The consumer 10 also has a business relationship with the application provider 6. For example, the application provider may have configured the user profile of the consumer 10 using the user ID and password. The consumer in this context can be, for example, a person, a household, or a company.

The agent device 4 (e.g., a sensor) includes authentication information for authenticating itself to the registry 8. For example, the agent device 4 may have a key that can be used to verify its identity. Thus, the registry 8 can check the identity of the agent device 4 and verify that it is a trusted agent device. Similarly, the registry 8 and the application provider 6 can exchange keys to confirm each other's identity and establish a trusted relationship. When the registry 8 establishes trust with both the agent device 4 and the application provision device 6, the registry 8 will not provision the application key to both the agent device 4 and the application provision device 6 . The application key provided by the registry 8 is then used to encrypt communications between the agent device 4 and the application provider 6 without any need for communication via the registry 8. [ The registry 8 thus ensures that the agent device 4 and the application provider 6 do not need to establish a direct trust between them and that the trusted communication between the agent device 4 and the application provider 6 . This is because the agent device 4 may be a small ultra-low power device (such as a temperature sensor or heart rate monitor) that has little processing power to implement the encryption algorithm and the protocol for identifying the identity of the application provider 6 useful. Also, the person installing the agent device 4 often may not have the knowledge or information to perform complex configuration applications to establish trusted communications with the application provider 6. The registry eliminates the need for the user or installer of the agent device 4 to know how to configure trusted communications.

It should be noted that there is no relationship between the consumer 10 and the registry 8 in Fig. The registry 8 does not have any details about the consumer, such as user ID or password, so no personal details are transmitted or stored by the registry. The relationship (10) of the consumer corresponds only to the application provider (6). The registry 8 only communicates with the agent device 4 and the application provider 6 and does not communicate with the consumer 10. Thus, the registry 8 is a neutral platform for establishing trust between the agent device and the application. Once a trusted communication has been established between the agent device 4 and the application 6, direct communication between the agent device and the application proceeds without the registry involved.

In other instances, there may be no consumer 10 as shown in FIG. 2 and instead the agent device 4 may belong to the same organization operating the application providing device 6. For example, a smartly connected city may have object internet devices for monitoring street lighting, traffic flow, or garbage collection, for example, around the city, and the city manager may have an agent device 4 (E.g., the application may be able to monitor the data obtained by the agent device 4) and possess one or more application provision devices 6 for processing the data And provide a cloud platform that can be accessed to report problems). In this case, there may not be a consumer 10 associated with a particular agent device 4 as shown in Fig. Nevertheless, the use of the registry 8 simplifies the installation of the agent device 4. For example, a contractor installing the agent device 4 in a streetlight or trash bin would not need to know how to configure the agent device 4 to communicate with an application that receives data from the agent device 4. Instead, the agent device automatically communicates with the registry 8 to establish a trusted relationship with the application 6 at the activation of the agent device 4 (e.g., upon power up or deployment of the agent device) can do.

3 shows an exemplary timeline showing the progress of the agent device (sensor) 4 until communication with the application provider 6 is established through registration and authentication with the registry 8 from its manufacture. In step A, the system on chip (SOC) for the agent device is made of silicon. In step B, an original equipment manufacturer (OEM) and / or an original device manufacturer (ODM) manufactures the agent device 4 using the system-on-a-chip. At some point during manufacturing, a unique device identifier is embedded in the agent device 4, along with key information for authenticating the identity of the agent device and other metadata for the agent device. In step C, the agent device is deployed. For example, the user 10 may purchase the agent device 4 from a store, and the agent device may be provided to an agency such as a weather forecasting station or city government. During the manufacture of step B or during the distribution of step C, registration information is provided in the registry 8 to register the agent device 4 as a trusted agent device in the registry 8. The registry 8 may be provided with key information for confirming that the agent device 4 is trusted as well as other metadata for the agent device 4. [

At this time, the registry 8 knows that the agent device 4 with the unique ID is a trusted agent device, but it does not know which cloud service application will use the data from the agent device 4. [ Thus, at step D, a binding operation is performed to link the user 10, the agent device 4, and the cloud application 6. For example, the agent device may have some kind of device identifier, such as a reference number, a bar code or a Quick Response code (QR code). The application provider 6 may provide a web interface or smartphone or tablet application for entering a device identifier, scanning a barcode or QR code, and uploading the device identifier along with the user identifier to the application provider 6. [ Alternatively, it may be performed by the application provider at the time of registration of the consumer to the application provider and subsequent allocation and dispatch of the agent device to the user. At this time, the cloud service knows which user owns the agent device 4, and then notifies the registry 8 of the device identifier to be registered for use in the application 6, 6) should communicate with the agent device 4. In this way the user of the agent device 4 does not recognize that the registry 8 exists and the agent device 4 stores information linking the agent device 4 to a particular cloud service or application provider 6 A link between the agent device 4 and the application provider 6 can be established in the registry 8,

In step E, the agent device is deployed, for example, by installing the agent device in the field as part of the Internet of things, or by first turning on the agent device. Upon activation of the agent device 4, the agent device 4 automatically contacts the registry 8 using the registry address stored in the agent device 4. [ The agent device 4 and the registry 8 are now mutually authenticating each other using key information that was embedded in the agent device 4 in step B and registered in the registry 8 during registration of step B or C to establish trust do. If the mutual authentication is successful, the registry 8 provides the application key to the agent device 4 and the application provider 6, and at step F, the agent device 4 and the application provider 6 receive the application key from the registry 8 And can securely communicate by encrypting and decrypting the message using the received application key. Thus, the registry 8 allows trust to be established between the agent device 4 and the application 6 without the need for the agent device to perform any complicated configuration.

In summary, the registry 8 provides an architecture for managing authentication of trust between an IOT device (e.g., sensor) 4 and an application provisioning device (cloud provider) The registry 8 manages the metadata for each application provider 6 and agent device 4 and manages the relationship between the agent device 4 and the application provider 6 and authenticates the device identifier , And a cloud platform that provides keys to enable secure communication to agent devices and applications. The agent device 4 can be manufactured according to a specific design guideline that ensures that the agent device 4 has a unique authenticable identity, secure key store, and encryption capability to secure trust, and predictable platform robustness And can be designed. The agent device manufacturing support platform can support key generation and interfacing with the registry as well as insertion into the agent device 4 and management of the key pair.

This architecture helps to solve some problems in existing systems. By providing each agent device with a unique identifier that is authenticated by the registry cloud service, the agent device can be uniquely identified to ensure trust. Preferably, the device identifier may be globally unique so that no two devices share the same identifier throughout the world. This means that the fabrication and allocation of device identifiers can be completely independent of any subsequently used registry. However, it is also possible that the device identifiers are locally unique within a given registry or registry group, and that the same identifiers are used for different devices in independent, non-interacting registries. Mutual authentication between the agent device 4 and the application 6 is achieved and through the automatic registration process of securely pairing the agent device with the application, the application trusts the agent device authenticity and the agent device trusts the application authenticity . Since the agent device 4 and the application 6 can now trust each other, even if they are not manufactured or distributed by the same provider, this can be done by opening the market for agent devices and applications, It is not necessary to use the agent device 4 of the specific brand provided by the agent device 6. An application can trust a wide range of agent devices from a plurality of manufacturers and agent devices can trust a wide range of applications from a plurality of providers. This will help reduce the cost of agent devices and applications and also help to increase the use of object Internet agent devices and applications. The registry 8 also helps to increase the reliability of the application provider to the source of sensor data for "Big Data" applications that process large amounts of data received from many sources. The value of the information collected for the "Big Data" service depends on the validity of all the "Little Data" collected by the individual agent device 4. If the cloud service can not trust its respective agent device 4, the conclusions obtained by the "Big Data" can also be unreliable, rendering the entire application meaningless. The technology helps to maintain confidence in the overall information gathered by these applications. The registry 8 can also store other information such as agent device characteristics and usage history of the agent device 4. [ This can be used to allow the application provider 6 to target a particular kind of agent device 4. For example, the application 6 may only want to collect data from the agent device 4 with a certain minimum security requirement.

Fig. 4 schematically shows the agent device 4. Fig. The agent device includes a sensing circuit (11) for collecting sensing data. For example, the sensing circuit 11 may include a temperature sensor, a camera, a heart rate monitor, or any other detector for collecting data required by the application provider 6. The agent device 4 may also be used to control various processing operations performed by the agent device 4, such as, for example, mutual authentication, encryption of data transmitted to the application providing device 6, And a processing circuit (12). The agent device 4 also has a communication circuit 14 for communicating with an external device such as the registry device 8 and the application providing device 6. The communication circuit 14 may be a communication using a wireless local area network (WiFi), a short distance communication such as radio frequency communication (RFID) or near field communication (NFC), or a communication used in a wireless sensor network such as Zigbee or Bluetooth or 6LoWPAN Of wireless communication. The communication circuit 14 may also use a cellular network such as 3G or 4G. The communication circuit 14 may also use wired communication such as an optical fiber or a metal cable. The communication circuitry 14 may also utilize two or more different types of communication, such as an example of several combinations of the examples given above. The agent device also includes a storage circuit 16 for storing the device identifier of the agent device 4, authentication information for authenticating the agent device, and other information used by the agent device 4. [ The agent device may optionally also include a key generator 18 for generating key information or other authentication information for the agent device 4. [

Fig. 4 shows an example in which the agent device is a sensor including the sensing circuit 11, but in another example, the sensing circuit 11 may not be necessary. Instead, for example, the agent device may include control circuitry for controlling physical objects such as, for example, a sprinkler, a burglar alarm, a heating or air conditioning unit, or a traffic signal light system.

Fig. 5 schematically shows an example of the information stored in the storage circuit 16 of the agent device 4. Fig. The storage circuit 16 has a one-time programmable (OTP) area 20 for storing a device identifier 22 that uniquely identifies the agent device 4. [ The device identifier 22 is embedded in the OTP area 20 during the manufacture of the agent device 4. [ In this embodiment, once fixed in the OTP area 20, the device identifier 22 can not be changed. For example, after the device identifier is written to the OTP area 20, the fuse may be burned in the storage circuit so that the OTP area 20 can not be rewritten. Alternatively, new identifiers may be generated for some devices after device fabrication. For example, when migrating a device to a different registry, it may be possible to assign a new identifier to the device to avoid conflicts with the identities of the devices already managed by the new registry.

The storage circuit 16 also includes a non-volatile memory area 24, which can be read and written, but which can be accessed only by privileged software that is read and write protected and applied by the processing circuitry 12 . The read / write protected area 24 stores a registry address 26 that contains a URL, IP address or other identifier that allows the agent device 4 to contact the registry 8. The protected area 24 also stores a registry public key 27 for decrypting the message received from the registry 6 to verify that the registry 6 is authentic (registry public key 27) Corresponds to a registry private key maintained by the registry).

The protected area 24 also stores a sensor key 28 or private key 29, which is a unique key maintained by the agent device 4 to uniquely identify its identity. The sensor key 28 is a symmetric key shared with the registry 8. The message may be at least partially encrypted using the sensor key 28 and if the registry 8 can successfully decrypt the message using the same key, the message is considered to have been received from the trusted agent device The device is authenticated accordingly. Alternatively, the agent device may be provided with a private key 29 corresponding to a different public key maintained by the registry 8. This asymmetric key pair allows for a more secure authentication of the agent device since no other device holds the private key 29 of the agent device 4. [ The public key 32 corresponding to the private key 29 may be placed in the write-protected but read-protected area 34 of the storage circuit 16. Thus, the public key 32 may be read by any device or by any software executing on the agent device 4. [ The digital certificate 36 associated with the agent device 4 is also stored in the open area 34 of the storage circuit 16. The digital certificate includes a public key 32 as well as various data and metadata identifying the agent device 4. This certificate is sent to the registry 8 during authentication, and the registry signs the certificate to authenticate the agent device identity. The other devices can then read the certificate from the registry 8 and the signature of the registry confirms that the agent device is trusted and the public key 32 associated with the certificate 36 is actually from that agent device. Thus, the registry 8 can serve as a certificate authority for authenticating the public key 32 in a manner similar to other certificate authorities in the public key infrastructure (PKI).

The read / write protected area 24 also stores one or more application keys 30, which are symmetric keys for performing trusted communications with the application provider 6. These keys are used by the registry 8 to encrypt / decrypt data or commands exchanged by the agent device 4 and the application provider 6. [ Different application keys for each pair of agent device 4 and application provider 6 are provided by the registry 8 to maintain the security of communications between the devices. In another embodiment, an asymmetric key may be used as the application key 30 provided to the device 4 and the application provider 6. The application key provided by the registry device 8 may be generated by the registry device 8 itself or may be obtained by a registry from another device such as a hardware key generator or key storage device.

Fig. 6 shows an example of the application providing apparatus 6. Fig. A communication circuit 40 is provided for communication with the registry 8 and the agent device 4. Again, different forms of wired or wireless communication may be provided as discussed above for the agent device 4. The application providing device also includes a storage circuit 42 for storing various data and applications used by the application providing device 6. [ For example, the storage circuit 42 may be configured to use the data received by the communication circuit 40 from the agent device 4 and to process it in a predetermined manner, or to send the control command to the agent device 4, You can save the program. A processing circuit 44 is provided to run the application and to control other operations such as authentication of the registry 8, encryption / decryption of data exchanged with the agent device 4, and the like. Encryption features such as encryption algorithms or security processing functions within the secure memory and processing circuitry 44 within storage circuitry 42 may be provided.

7 shows an example of a registry device 8 for maintaining a device registry. The registry 8 has a communication circuit 50 for communicating with the agent device 4 and the application providing device 6. Once again, the communication circuit 50 may utilize the various types of wired or wireless communication discussed above. The registry also has a storage circuit 52 for storing a program executed by the registry 8 and for storing a device registry for tracking information about the various agent devices 4 and corresponding applications 6. [ Executes the application program stored in the storage circuit 52 and performs authentication of the agent device 4 and the application provider 6, transfer of the agent device 4 between different registries, and management of metadata for the agent devices There is provided a processing circuit 54 for controlling the operation of the microcomputer. Once again, encryption features such as encryption algorithms or security processing functions within the secure memory and processing circuitry 44 within the storage circuitry 42 may be provided. The registry 8 may also be responsive to queries from external devices for information about certain agent devices 4, such as information about which authentication model is used by the agent device. For security reasons, not all the registry 8 may allow this query. For example, some registry operators may prefer not to provide information about the authentication model used by a particular agent device 4. In addition, the registry 8 may perform authentication of the querying device prior to responding with information about the agent device 4 to ensure that only the trusted querying device is allowed to acquire this information.

FIG. 8A shows an example of a registry entry 60 stored by the storage circuit 52 of the registry device 8. FIG. Each of the agent devices 4 registered in the registry has a registry entry 22 containing the device identifier 22 of the agent device 4 (corresponding to the identifier 22 stored in the OTP area 20 of the agent device 4) Lt; / RTI > The registry entry also includes the device certificate 36 of the agent device 4 and other authentication information used by the registry 8 to verify that the public key 32 and the agent device 4 are trusted . Although FIG. 8A shows an example having a certificate 36 and a public key 32 in the same field, they may also be provided in different fields. The registry entry 60 may also have fields for other types of authentication information for use in other authentication models.

The registry entry 60 also includes one or more application identifiers 62 identifying the one or more application providing devices 6 with which the agent device 4 intends to establish trusted communications and the identified application providing device 6 And one or more application keys 30 for communicating. Once again, the application identifier 62 and the corresponding application key 30 may be in the same or different fields of the registry entry 60. The application identifier may be stored in the registry entry in response to a request from an application provider associated with the agent device. Thus, the agent device itself does not need to know which application it is communicating with, and the registry 8 can provide a link between the agent device and the application providing device. For example, once the agent device receives the application key 30 from the registry 8, the agent device can simply send the encrypted data using the application key 30 without worrying about where the data is going Can be output.

The registry entry 60 also includes authentication model information that identifies which authentication model the agent device 4 uses to authenticate itself, as described below. It will be appreciated that registry entry 60 may include many other types of information and metadata for an agent device that may be queried by an external device, such as an application provider. It will also be appreciated that the agent device 4, the application provider 6, and the registry 8 may include many other elements than those shown in Figures 4, 6, and 7.

The registry entry 60 also includes a signature / hash field 68 containing a trusted signature or hash value generated based on at least some of the other fields of the registry entry 60. This allows operation detection if the device or person attempts to modify one of the other fields after the registry entry 60 is first created in the registry. The registry device 8 may use the other fields to recalculate the signature or hash and check whether it matches the stored signature / hash field 68.

As shown in FIG. 8B, the registry device 8 may also store an event entry 69 for the corresponding agent device 4. The event entry 69 may be a sub-entry of the registry entry 60 shown in FIG. 8A, or, in another embodiment, as a separate record associated with the registry entry 60 by the device ID 22 . The event entry 69 provides history information about an event that may occur in the corresponding agent device 4. [ A particular agent device 4 may have zero, one, or multiple event entries 69 associated with it. Thus, there can be a one-to-many relationship between a registry entry 60 for a particular device and an event entry 69 associated with the same device. The event entry 69 includes a device ID 22 for the agent device, date information indicating the date the event occurred, an event record indicating the type of event that occurred and any other information associated with the event, Hash / hash field for operation detection similar to signature / hash field 68. A new event entry 69 may be generated upon the occurrence of an event associated with the agent device 4. [ For example, an event that may be recorded includes dispatching, shipping (place), activation or deactivation of the device, registration of the device by the consumer, and many others, after the manufacturing of the agent device 4. The event entry 69 allows the registry to track the history of the device.

As shown in FIG. 9, different types of agent devices 4 may have different requirements for security and authentication. In general, the higher the level of security required (for example, because the data is valuable, personal, commercially sensitive, or has health or public safety concerns associated with data use), the more The cost of manufacturing the agent device 4 is higher because complicated resources can be required. For some devices, this additional cost may not be justified. For example, in the case of an agent device such as a thermometer that supplies data to a weather monitoring application, a relatively low cost and low security authentication model can be used because the data is all that is required to be authentic. On the other hand, for other types of devices used in healthcare or smart cities or telematics, it can be very important that agent device integrity and authenticity are not compromised. For these applications, it can be justified to incur an increase in cost in order to obtain a higher degree of security. Thus, as shown in FIG. 9, a plurality of different trust levels can be established to provide a scalable technology for maintaining authentic device identity for IOT devices. Each agent device 4 may have a particular authentication model selected for it and the selected model may be displayed in the registry entry 60 using authentication model information 64 as shown in FIG. There may also be a commercial need for devices with similar functionality with authentication models that operate at different security levels. This may be useful in providing different applications.

By establishing different agent devices 4 with different authentication models during the manufacture or distribution of the devices, the registry 8 can divide or separate the agent devices into different categories based on the authentication model information 64. For example, certain applications 6 may specify that they can only communicate with an agent device that has a particular authentication model. The devices may also query the registry 8 to determine the authentication model for the specified agent device 4. For example, the banking application provider may wish to set up that the user's existing agent device 4 meets certain minimum security requirements before establishing a trusted communication with the agent device 4. [ Different authentication models may differ in many different ways. For example, some authentication models may use fixed, immutable authentication information while other authentication models may allow authentication information to be updated using the key generation circuit 18 of the agent device 4 . In the case of the fixed model, the agent device may be implemented at a lower cost, since the key generation circuit 18 may not need to be provided to the agent device 4, while in the case of an agent device with key generation capability, The key can be generated, so a more secure authentication can be provided. Similarly, some authentication models may use a symmetric key shared by the agent device 4 and the registry 8, while other devices may use an asymmetric key with the agent device 4 and registry 8 having different complementary keys Can be used. Some models may allow migration of agent devices from one registry to another, while others may constrain agent devices to work with a particular registry. Thus, there are many different ways of implementing an authentication model that can be appropriately selected during the manufacture and development of an agent device.

10 to 12 show three examples of the authentication model. 10 shows a first authentication model in which a fixed sensor key 28 is injected into the protected area 24 of the agent device 4 during manufacturing. The sensor key 28 is generated by an external device 70 belonging to the manufacturer. The sensor key 28 is then shared with the registry 8 as a shared secret that uniquely identifies the device. For example, the sensor key may be a 128-bit or 256-bit Advanced Encryption Standard (AES) key generated during manufacture. In order to authenticate the agent device 4, the agent device 4 can send a message to the registry 8, a part of which is encrypted with the sensor key 28. The authentication of the agent device 4 is successful if the registry 8 can successfully decrypt that part of the message 28 and confirm that it is correct using a copy of its own sensor key 28. [ For example, a hash may be generated from the message by the sensor key 28 and the agent device 4 used to encrypt the hash. The registry receiving the message can generate a hash of its own received message using the same algorithm as the agent device 4 and can also decrypt the received hash to check if it matches the hash it has generated have. If the two hashes match, the agent device is authenticated. An advantage of the first authentication model is low implementation cost. It is not necessary to provide the public key infrastructure or the key generator 18 at the agent device 4. [ Only AES, or any other shared secret, is required. However, lower costs come at the expense of reduced security, because shared secrets provide complete control of the device or agent device, including owner changes or data access, if corrupted. Since the shared sensor key 28 provided in the registry 8 is the same as the sensor key 28 used to authenticate the device, The potential for exposing the sensor key 28 is greater than the use of asymmetric keys. However, since the sensor key 28 is unique to each agent device 4, even if the sensor key is compromised, it will only affect one agent device 4 and will not affect any other agent devices . Therefore, this model can be used for low security applications such as weather forecasting.

In some embodiments, instead of having a single sensor key 28, a list of sensor keys may be embedded within the agent device 4, and a key from the list may be used by the agent device 4 to authenticate itself Lt; / RTI > In this case, the active identification of the device may be defined using an index into the list indicating which key is the selected key. The registry 8 may then be provided with a corresponding agent device key for the selected key. With this approach, even if one sensor key is compromised, the agent device 4 can switch to use another sensor key from the list.

11 shows that the authentication information for the agent device 4 is still fixed (unchangeable), but this time the authentication information is transmitted to the second device 2 including the asymmetric key pair including the private key 29 and the public key 32 And shows an example of an authentication model. This is more secure because the private key 29 can only be held by the agent device 4 and is not shared with any other device while the corresponding public key 32 exposes the private key 29 And can be broadcast widely to other devices without having to. The asymmetric key pair is to allow the partially encrypted message to be decrypted using the corresponding public key 32 using the private key 29 in a manner similar to that discussed above. Thus, if the registry 8 can successfully decrypt a message received from the agent device using the public key 32, then it can be assured that the message came from an authenticated agent device with the private key 29 . The key pair is also associated with a digital certificate 36 representing the public face of the agent device 4. The certificate 36 can be used to transfer the public key 32 to the registry 8 and once signed by the registry it verifies that the public key 32 is the correct key for the agent device 4. [ The key pair and certificate may include any type of signed certificate and key pair. For example, elliptic curve cryptography (ECC) keys may be used as the key pair 29, 32, and an X.509 certificate may be used as the digital certificate 36. In this model, the manufacturing device 70 generates key pairs and certificates 36 during manufacturing and embeds them in the protected areas 24, 34 of the memory as shown in FIG. There is a potential vulnerability in that the manufacturing process 70 will know the private key 29 of the agent device 4. Once the private key has been injected into the agent device 4, (29), and then the agent device (4) will be the only device with access to the private key. The private key is not required by any part other than the agent device 4 itself. The transfer of authentication information from the manufacturer 70 to the registry 8 is more secure because it requires only the transfer of the public key 32 and the certificate 36 and the private key 29 does not . However, in this model, since the agent device requires more protected memory to store the PKI capability and the private key 29, the public key 32 and the certificate 36, . However, since there is no permanent shared key known by devices other than the agent device 4, security is higher. Once again, the agent device 4, rather than a single key pair, may have a list of key pairs available for selection once the agent device has been running. Nevertheless, the list does not have significant protection requirements, since in this case the list of agent devices maintained by the registry 8 consists only of public keys and certificates. Any known PKI scheme may be used for the second model.

Figure 12 shows a third authentication model that is more secure than the first and second models but is more expensive to implement. Once again, the private key 29 and the public key 32 are provided to the storage circuit 16 of the agent device 4 along with the digital certificate 36. However, the third model is different from the second model in that the on-chip key generation circuit 18 is provided to the agent device 4 to generate the key pair 29, 32. This provides more security because the manufacturer 70 never knows the private key 29 of the agent device 4. Also, since an on-chip key generation facility is provided, the agent device can regenerate the key pair to change the authentication information if necessary. Only the public key 32 and the certificate 36 are provided to external devices such as the registry 8. [ Thus, during identity and ownership establishment, the chipset 18 in the agent device 4 generates an asymmetric key pair, such as an ECC key pair. The private key 29 is stored in the read / write protected area 24 of the memory. Only the privileged code accesses the private key 29. The on-chip key generation circuit 18 also generates a certificate 36 and sends a certificate signing request including the device ID 22 and the public key 32 to the registry 8. The public key 32 and the certificate 36 are also written into the write-protected area 34 of the fully readable memory without protection. The registry 8 signs the certificate 36 to confirm that the agent device is authentic. This method does not have exposure vulnerability of models 1 or 2 in which sensor key 28 or private key 29 can be extracted from registry 8 or manufacturing platform 70. The private key 29 of the agent device is never exposed to any device other than the agent device 4. [ In this case, the strength of the security depends on the quality of the key pair by the on-chip key generator 18, and in order for it to be secure enough to support secure key generation (e.g., good random number generation will be required) Additional silicon is needed, which adds to the cost of device fabrication.

In the example of FIG. 12, the third authentication model also allows the trusted relationship between the registry 8 and the agent device 4 to be transferred to the second registry 80. This process will be described in more detail later. Since the agent device 4 has the on-chip key generation circuit 18, when it transfers the agent device trust from the first registry 8 to the second registry 80, a new key is generated and stored in the first registry 8 ) Can no longer authenticate the agent device (4). This provides additional security because the operator of the private registry 8 for use in government or defense applications, etc. may require that certain agent devices be transferred to the registry and all bindings with the public registry 8 removed . ≪ / RTI > Alternatively, the first registry may be instructed to delete the associated entry so that it can no longer authenticate the agent device. In this way, the agent device does not need to generate a new key. In another variation, the agent device may have more than one pre-stored key. Upon changing the registry, the old unused key may be used.

It will be appreciated that it may also be possible to provide the ability to transfer trust between the registries for the other models of Figures 10 and 11. [ However, in this case, since the agent device can not regenerate the key information, the agent device 4 will be registered with the same key information in the second registry 80. In this case, the two registries 8 and 80 may share the same agent device 4 so that the same agent device 4 is registered in both registries. Thus, rather than transferring the agent device data directly to another registry, the agent device may instead be assigned to both registries so that the agent device can communicate with the application provider associated with both registries.

Thus, a number of different types of authentication models are provided to allow the agent device design to maintain a balance between the ability to maintain a sufficient degree of security and the cost of implementing security. Depending on the intended purpose of the agent device, information about which particular model was selected and which model was used during manufacture may be maintained by the registry 8 to allow applications to use the appropriate agent device for their requirements . Figure 13 shows a table comparing the different attributes of the models shown in Figures 10-12. It will be appreciated that other types of models may be used. For example, different types of key generation may be used to provide different degrees of security.

14 shows a first example of a method for establishing a trusted identity for an agent device 4. [ A trusted identity may be established during the manufacture of the agent device, during its distribution, or upon registration of the device to the registry at a later time. At step 100, an authentication model to be used for the agent device 4 is determined. If the agent device 4 has already been manufactured, the determination of the selected authentication model will depend on what resources have already been provided to the agent device 4 (for example, if the agent device does not have the on-chip key generation circuit 18 , The authentication model (3) discussed above will not be selected). On the other hand, if this method is performed during or prior to manufacturing the agent device, any authentication model may be selected (such as building a protected repository, PKI infrastructure, or key generation capability into the device) The processing resources required to do so may be implemented later.

At step 102, key information for authenticating the agent device 4 is generated according to the selected authentication model. This can be done by the external manufacturing device 70 or by the agent device 4 itself, depending on the selected model. At step 104, a device ID 22, a shared sensor key 28 or private key 29, a registry address 26 and, optionally, a device certificate 36 are stored in the storage circuitry of the agent device 4 16). The embedding step may be implemented by building a storage circuit in the device, or by storing information in a storage circuit already provided in the agent device during a previous stage of manufacturing. If authentication model 1 is used, sensor key 28 is embedded, whereas if authentication model 2 or 3 is used, private key 29 and certificate 36 are stored in storage circuitry 16. At this time, the agent device 4 may also be provided with registry authentication information for confirming the identity of the registry 8. [

At step 106, various metadata for defining the trusted identity of the agent device is uploaded to the registry device 8. [ For example, the device ID 22, the sensor key 28 (in the case of model 1) or the public key 32 (in the case of model 2 or 3), the digital certificate 36 (in the case of model 2 or 3) And authentication model information 64 indicating the selected model may be uploaded to the registry 8. At step 108, the registry signs the certificate, if necessary, and registers the device metadata in the registry to establish the device as a trusted device whose identity can be authenticated.

Figure 15 shows a second example of establishing trust and identity for a device. In this example, the agent device (sensor) 4 has already been manufactured with the key generation circuit 18, and the device identifier 22 has been stored in the OTP area 20 of the storage circuit 16. [ Thus, an authentication model 3 or a similar model that allows for on-chip key generation is used by this sensor 4. At step 120 the sensor 4 sends a registration request to the registry 8 specifying the device identifier 22 of the sensor 4. In step 122, the registry checks if the sensor 4 is already owned by the registry, and if so, the method ends.

If the agent device is not already owned, then at step 124 the sensor 4 is triggered to generate a new key pair 29,32 using the key generator 18 and the private key 29 of the key pair Is placed in protected storage area (24). At step 126, a certificate signing request is generated and sent to the registry 8. The certificate signing request requests the registry 8 to sign the digital certificate 32 of the sensor 4. The certificate includes at least the device identifier 22 of the sensor 4 as the subject name, the security level of the sensor 4 (authentication model information), and the public key 32 generated by the key generator 18. At step 128, the registry 8 signs the certificate and verifies that the certificate and public key are valid. The registry registers information on the sensor 4 in the device registry to establish the sensor 4 as a trusted agent device.

16 shows how to perform authentication of the agent device 4 to check whether it is registered as a trusted device and to establish a trusted communication between the agent device 4 and the application providing device 6. [ The agent device 4 has already been registered in the registry 8 using the method shown in Fig. 14 or 15 for example, And authentication information that uniquely identifies the authentication information. In this example, the authentication model 3 is used agent device 4 Sensor private key K _s include _.pr registry and 8 is the private key K _{s .pr} sensor public key K _s corresponding _{to. pu} . Similarly, the agent device 4 is _configured to _register the registry public key K _{r. R} corresponding to the registry private key K _{r. Pr} held by the registry 8 _{. pu} can be used to authenticate the registry 8.

At step 150, the registry 8 and the application provider 6 perform mutual authentication of each other to establish trust. Typically, this will be done once for each application provider 6 by the registry 8. The mutual authentication 150 between the registry 8 and the application provider 6 will not normally be repeated for each agent device 4 that wants to communicate with the application provider 6. Mutual authentication 150 may be accomplished using any known authentication technique.

At step 152 the agent device is activated and in response to activation the agent device 4 sends an authentication request 154 to the agent device's protected storage 24, Transfer to the registry. The authentication request includes a device ID 22 that identifies the agent device 4. Activation of an agent device may include, for example, an agent device being powered on for the first time after installation, or an activation button on the agent device being depressed. The authentication request 154 is automatically sent in response to activation of the agent device so that there is no need for a user interface or any other kind of user interface to trigger authentication. This means that a person installing or using the agent device need not know whether the agent device is authorized or not. In response to the authentication request 154, the agent device 4 and the registry 8 perform a mutual authentication 156 using the keys already exchanged by the agent device 4 and the registry 8 during registration or listing . In mutual authentication, the agent device 4 encrypts the hash of the message using the sensor private key K _{s. Pr} and sends the partially encrypted message 158 to the registry 8. In a corresponding manner, the registry 8 encrypts the hash of the message using the registry private key K _r.pr and sends the partially encrypted message 159 to the agent device 4. The agent device 4 obtains a hash of its own message 159 and stores it in the registry public key K _r. and compares it with the hash obtained by decrypting the hash encrypted with _pu . If the two hashes match, the registry 8 is assumed to be true. Similarly, the registry 8 obtains a hash from the message 158 and sends it to the sensor public key K _{s . pu} to the hash obtained by decrypting the encrypted hash received along with the message 158. [ Once again, if the two hashes match, the agent device 4 is authenticated.

Figure 16 shows a separate authentication request 154 and an authentication message 158 sent by the agent device 4. In another embodiment the authentication request 154 and the authentication message 158 are the same message The agent device 4 sends a partially encrypted authentication message 158 (along with the device ID 22) to the registry 8 at the time of activation 152, 156 as an authentication request to trigger the response.

If the registry 8 successfully authenticates the received message 158 from the agent device 4 then at step 160 the registry 8 generates the application key 30 and sends this application key to the agent device 4. [ Lt; / RTI > The registry 8 also identifies the application key 30 by the application identifier 62 in the registry entry 60 for the agent device 4 with the device ID 22 specified in the authentication request 154 To the application provider (6). The registry 8 also sends the agent device ID of the agent device 4 to the application provider 6 so that the application provider 6 uses the received application key 30 to determine which agent device 4 is communicating Let's know whether to do it.

If the agent device 4 has successfully authenticated the registry 8 then at step 170 the agent device 4 and the application provider 6 are authenticated using the application key 30 received from the registry 8 Communication is started. If the registry 8 is not successfully authenticated by the agent device 4, then the agent device 4 does not participate in any encrypted communication with the application key 30. In the encrypted communication 180, typically the agent device 4 will send the data to the application provider 6 and the application provider will send the command to the agent device 4, It can also be possible. In step 190, the application running on the application providing device 6 processes the data received from the agent device. For example, an application may use this data to determine additional information or use this data for a cloud computing platform that may be accessed over the Internet. The encrypted communication 180 proceeds directly between the agent device 4 and the application provider 6 without proceeding through the registry 8.

Thus, the registry 8 allows the agent device 4 and the application provider 6 to encrypt communications without requiring complex configuration or user interaction at the agent device 4. This means that the agent device 4 does not need to have very simple and complex processing resources, while security can still be maintained.

17 shows a method for associating an agent device 4 with a specific consumer (user) 10 and associating the agent device 4 with an application provider 6 in the registry 8. At step 200, the consumer 10 obtains the device ID 22 of the agent device. This can be done in a variety of ways. For example, a box for the agent device 4 or the device 4 can print the device ID on its surface, and the consumer can read the device ID from the agent device case. In addition, the device ID may be represented by a barcode or QR code or a similar graphical representation, and the user may use a code reader to scan the code to obtain the device ID 22. The consumer 10 then sends to the application provider 6 a device association request 210 that includes the consumer's identifier (user ID) and the device identifier 22. This step can occur automatically, for example, in response to reading a bar code or QR code using a smartphone or tablet app or web interface. The application provider 6 can now log the user ID against the device ID so that subsequent communication from the agent device 4 can be associated with a particular consumer. After receiving the device association request 210, the application provider 6 may also send an application association request 220 (e.g., an application identifier) that links the application identifier of the application provider 6 to the device ID 22 from the agent device association request 210 ) To the registry (8). In response to the application association request, the registry 8 registers the application identifier in the registry entry 60 for the agent device with the device identifier 22 specified by the application association request 220.

In another example, the consumer 10 may have obtained the agent device 4 directly from the application provider so that when the consumer acquires the agent device, the application provider 6 may already know the link between the device ID and the user ID have. In this case there is no need for a device association request 210 so the application provider 6 may instead generate an application association request 220 to be sent to the registry 8 using its internal record. Note that the registry 8 does not receive the user identifier. The registry entry 60 identifies the agent device 4 only by the device ID and does not contain any user data.

In a similar manner the application association request 220 may also be used by the application provider 6 to request that the agent device 4 currently associated with one application provider 6 be transferred to a different provider 6 have. The application association request 220 may in this case be used by the agent device itself (e.g., if the user chooses to switch the application provider), the old application provider 6 that was previously associated with the agent device 4, The request may come from a variety of sources, including the new application provider 6, or other third party device, to which the device is assigned using the request 220. The registry 4 may check whether the device performing the application association request 220 is a trusted device prior to assigning the agent device 4 to the new application provider 6. [ Alternatively, if the agent device 4 is allowed to be associated with a plurality of application providers 6, it may be possible to replace the previous application provider 6, as in the example given above, Together, a new application provider 6 may be registered for the agent device 4.

18 shows a method of assigning the agent device 4 registered in the first registry 8 to the second registry 80. Fig. At step 250, the requestor device requests to transfer the ownership of the registered agent device 4 to the second registry 80. The requestor device may be an agent device 4, a second registry 80, or another third party device, such as an application provider (cloud service owner). In step 260, the first registry 8 checks whether the agent device 4 mentioned in the device allocation request is currently registered in the registry. If not, the method ends. Therefore, in order to be assigned the ownership of the agent device, it is necessary to request permission from the first registry 8 that currently has the registration of the agent device. This ensures that only the agent device and the registry that has already established trust can authorize the transfer of the trusted state to another registry 80.

In step 270, the first registry determines whether it trusts the requestor device that made the agent device assignment request. If not, the method ends. The first registry may have previously authenticated the requestor, in which case the requestor may be determined as a trusted requestor. Alternatively, at step 270, the registry may newly authenticate the requester if the requester has not been authenticated. Authentication between the first registry 8 and the requester may be performed using any known technique. Also, in some authentication models, the assignment of the agent device 4 to different registries may not be allowed, so the registry may check whether the authentication model information for the agent device is allowed to be assigned to the agent device.

If the registry trusts the requester, then the agent device is allowed to migrate to a different registry, and the method proceeds to step 280, where the agent device 4 sends the key to the key generator 18, To generate a new key pair. The agent device 4 may be triggered to generate a new key pair in different manners. In one example, the first registry 8 may instruct the agent device 4 to be assigned to another registry, and in response to this indication, the agent device may generate a new key pair. Alternatively, the first registry 8 may notify the requestor device or the second registry 80 that a device may be assigned, and the device may then trigger the agent device to generate a new key pair . At step 290, the agent device 4 generates a certificate signing request including the newly generated public key and the device ID of the agent device 4. [ The private key corresponding to the public key is stored in the secure repository. The certificate signing request is sent to the second registry 80 and at step 300 the second registry 80 signs the certificate and registers the agent device 4 in its device register. At step 310, the agent device invalidates the original registry ownership by deleting the private key 29 from the original key pair and updating the registry URL 26 to correspond to the URL of the second registry 80. In step 320 the first registry 8 checks whether the agent device correctly migrated its registry ownership and then informs the second registry 80 that the agent device 4 is now in possession of the second registry 80 Under the same conditions. At this time, the first registry 8 may optionally delete the registry entry 60 for the agent device 4 so that the agent device 4 is no longer registered in the first registry. Alternatively, the entry for the agent device may remain in the registry because the public key 32 from the original key pair is no longer appropriate by the agent device 4 because its corresponding private key has been deleted.

The example shown in FIG. 18 is for a similar authentication model in which the authentication model 3 or agent device has the ability to generate a new key pair. If the agent device has a similar model with authentication model 2 or authentication information fixed, then at steps 280, 290 and 300, instead of generating a new key pair, the original key pair from the first registry and the certificate And the second registry 80 may be provided with the same authentication information as that originally registered in the first registry 8. [ After the assignment, the agent device 4 can register with both registries 8, 80, be authenticated by both registries, and communicate with the application providing devices associated with both registries 8, 80.

The agent device 4 or the first registry 8 may take steps to ensure that the steps 280 to 320 occur automatically but that the steps are interrupted midway and it is not possible to remain unfinished. This is because, in the event of a failure on the way through the update process, the only possible result is that when the agent device 4 keeps the original key pair and certificate and is not sent to the second registry (step 270, (Similar to the case where the registry determines that the requester is untrusted), or the agent device is completely updated to be under the ownership of the second registry. This ensures that the agent device 4 can always communicate with one registry 8 or 80 and can not end unauthenticated by either registry 8,

In some cases, when assigning the agent device 4 to a new registry as shown in FIG. 18, the application provider 6 associated with the agent device 4 may also change. The second registry 80 may for example select which application (s) should be assigned to the agent device 4 or alternatively the second registry 80 may include an application provider (s) 6) from the external source, indicating the application identifier of the application. Alternatively, at the time of switching of the registry, the application associated with the agent device 4 may remain the same and the second registry 80 may simply be the same as that registered for the agent device 4 in the first registry 8 (E.g., the first registry 8 may provide the application identifier (s) to the second registry 80).

19 shows a method for resetting ownership of an agent device 4 that has previously been transferred to a second registry 80 so that ownership is returned to the management of the first registry 8 that registered the original agent device 4 Lt; / RTI > At step 350, the second registry 80 (requestor device) requests the first registry 8 to regain ownership of the agent device 4. In step 360, the first registry 8 determines whether the second registry 80 is trusted. Once again, this involves performing authentication, checking whether the requester has been previously authenticated, or determining whether the agent device 4 supports resetting to the first registry 8. If the agent device 4 is not allowed to be reset to the registry, the method ends. If not, the method proceeds to step 370, where the registry checks whether the agent device 4 is currently owned by the second registry 80. If not, the method ends. This ensures that only the current owner of the registration can trigger registration of the device 4 to be reset to the first registry 8.

If the agent device is owned by the second registry 80, a new key pair is created by the agent device 4 at step 380. At step 390, a certificate signing request is prepared with the new public key and device ID and this is sent to the first registry 8. The private key of the generator key pair is stored in the security store 16 of the agent device 4. In step 400, the first registry 8 signs the new certificate and authorizes the agent device one more time. At step 410, the agent device withdraws its registration to the second registry 80 by deleting the previous key pair and certificate and updating the registry URL 26 to correspond to the first registry 8. At step 420, the device ownership status is updated in the first registry 8 and the second registry 80 can delete that entry for the agent device 4. [ The method then ends. Once again, the operations in steps 380-420 can be performed automatically to ensure that the agent device is always registered to one of the registries and can not be terminated without valid registration in either registry.

The methods of FIGS. 18 and 19 allow an agent device to be transferred between the registries or to be assigned to multiple registrations at one time, which allows some operators to use their agent devices with other authorized agent devices Lt; RTI ID = 0.0 > a < / RTI > personal registry of their own agent devices. For example, a defense organization, government, or city manager can operate a registry of their own secure and trusted agent devices for use within an organization. A generic public registry can be provided for general use. Once the agent devices are manufactured, they can initially be registered in the public registry, but if the ownership change is requested by the private registry, they can be transferred to the private registry. If agent devices are no longer required by the private registry, ownership can be reset to the original registry. Advantageously, upon migration to a different registry, new authentication information may be generated to ensure that the agent device can no longer be authenticated by the old registry.

Figures 20-23 illustrate four examples of timelines that illustrate different applications for the present technique. Figure 20 shows a first example of a personal healthcare field in which an agent device (sensor) is tethered to a particular cloud application so that it is directly served by an application provider and can not be used in other applications. The agent device 4 may be a wrist-wearable sensor including, for example, a heart rate monitor capable of feeding heart rate information to an application provision device 6 operated by a healthcare provider to monitor a patient ' . In step (1), the chip IP company designs hardware and software for the sensor (4) and security design guidelines for the sensor. A system-on-chip (SOC) manufacturer creates an SOC that includes security hardware and a unique device identifier. The original device manufacturer (ODM) manufactures sensor devices. The original equipment manufacturer (OEM) develops the final product. At some point during the manufacturing process (which may be an SOC, ODM, or OEM stage), in step 2, a device identifier and a private key are installed in the agent device 4. In step (3), sensor metadata is uploaded to the registry (8) by the manufacturing support system (70). The metadata may include, for example, device identifiers, public keys, and authentication model information. The registry device 8 registers this information in its device registry.

In step (4), the sensor is sold to the healthcare provider (6). In step (5), the healthcare provider (6) provides the sensor to the user as part of its service. The healthcare provider 6 associates the sensor ID of the device with the user ' s ID. In step (4) or step (5), the OEM or application provider (6) provides an application association request to the registry (8) to notify the sensor (4) that it will be used in the healthcare provider's cloud application. Thus, the registry does not have customer information, but knows that when the agent device 4 is activated, the device will communicate with the application providing device 6 corresponding to the healthcare company.

At step 6, the user receives the sensor 4 from the healthcare provider 6. The user adjusts the cuff to fit his or her wrist and turns on the sensor 4 and starts using it. Turning the device on triggers the sensor 4 to contact the registry 8 with an authentication request, and mutual authentication is performed as described above. The user is unaware of this and there is no user interface to trigger this authentication - authentication is triggered automatically by activation of the device. The registry 8 determines whether the sensor 4 has already been registered in the registry and has an application identifier corresponding to the healthcare provider 6 in its registry entry. Thus, at step 7, the registry 8 notifies the healthcare provider of the device ID and informs the healthcare provider 6 that the agent device is now active with the validated device ID being authenticated. At step 8, the healthcare provider 6 requests an application key for secure communication with the sensor 4. [ In step 9, the registry provides application keys to both the sensor 4 and the healthcare provider 6. In step 10, a direct secure encrypted communication is initiated between the sensor 4 and the health care provider 6 without involvement of the registry.

Figure 21 illustrates another example of a use case where a user may purchase a "ready-for-purchase" device and later associate the device with a particular cloud application, instead of being tethered to the cloud application before the agent device is presented to the user / RTI > This allows the user to use different types or brands of sensors in the same cloud application. Once again, this example relates to personal healthcare where the application providing device belongs to a healthcare company. Steps 1-3 are the same as in Fig. However, in this case, in step (4), the OEM sells the product to the retailer and the retailer sells the sensor (4) to the end user. At this time, the sensor 4 is not assigned to the application provider 6.

At step 5, the user runs a smartphone app provided by the healthcare provider 6 and scanning the code on the box, either the sensor 4 itself or the sensor is packaged. The app on the smartphone sends a sensor association request to the healthcare provider that links the device ID of the sensor to a specific user account. In step 6, the smartphone app or healthcare provider's platform 6 sends an application association request to the registry 8 that links the application ID to the device ID. Thus, now the registry can associate an agent device with a particular application, and an application provider can associate an agent device ID with a particular user. Then, steps 7-11 of FIG. 21 proceed in the same manner as steps 6-10 of FIG. 20, respectively.

Figure 22 shows a third use case where the " buy your own device "sensor 4 is purchased by the user and the user is free to choose one of several different application providers for use with the sensor 4 Fig. The Internet of Things (IOT) App Store 400 is used to make this selection. The steps 1-4 of Fig. 22 are the same as those of Fig. Once again, the sensor 4 is sold to the retailer and the retailer sells it to the end user. In step 5, the user runs the app store 400 on a smartphone, tablet, or computer and once again uses a QR code or similar technique to collect the device ID of the sensor 4. [ In step 6, the App Store 400 validates the device ID of the sensor to the registry 8. For example, the app store 400 may query the registry 8 to determine the authentication model or other capabilities of the agent device used by the agent device and to prepare a menu of compatible apps that work with the agent device 4 can do. The user is provided with a menu of apps, selects the desired app, executes and logs in. In step 7, the app store updates the registry with the user's selection, causing the registry to associate the device ID of the sensor with the application identifier of the selected application. The App Store also sends the device ID and user ID of the sensor to the selected application provider 6 so that the provider 6 can link the user ID and the sensor ID together. At this time, the registry 8 knows which application the particular sensor 4 will communicate with, and the application provider knows which customer is associated with the sensor 4. Steps 22-12 in FIG. 22 are then identical to steps 7-11 in FIG. 21, respectively, where mutual authentication is performed between sensor 4 and registry 22, , A secure communication is established between the sensor (4) and the application provider (6).

23 shows a fourth use case in which the agent device 4 is used in a large-scale industrial or governmental organization rather than in personal healthcare. In this example, the agent device feeds back data to the cloud platform about the operation of streetlights and the like, and then uses the maintenance provider to determine, for example, 4). Steps 1-3 are once again the same as in Figures 20-22. In step (4), a product comprising the sensor is manufactured and provided to the contractor. For example, a streetlight lamp may be manufactured with integrated sensors, or alternatively, a product containing the sensor may be produced separately from the streetlight lamp to be installed on the streetlight lamp in a later stage. At this time, the registry may be updated to reflect the sale of the sensor 4 to a particular service provider 6, or alternatively it may be possible for the contractor to scan the product ID using a smartphone app or similar device, Positional data, at the time of installation of the sensor and the distance illumination at a later step (5). In step 6 the contractor's device may send the device ID of the sensor 4 to the registry along with the application identifier of the application 6 that will use the sensor data from the sensor 4. [ The smartphone app can, in a simple manner, allow the contractor to make association requests to link the sensor 4 to a particular application 6 without having to understand what the contractor is doing.

At step 7, upon activation of the agent device 4 (e.g. at power up), the agent device, such as a streetlight, contacts the registry directly to establish mutual authentication as discussed above. Once the authentication is established, in step (8), the registry registers the new streetlight and the agent devices with the service provider (6) that develops or deploys a system based on the Internet (IoT) . In step 9, the service provider 6 requests an application key for secure communication. In step 10, the registry 8 provides a symmetric application key to the service provider 6 and the agent device itself. The direct secure communication is then initiated and the IoT platform of the service provider 6 uses the sensor data provided by the sensor 4 to execute the application. A customer (such as a city manager or a maintenance contractor) may also access the IoT system using, for example, a web platform (step 11). Thus, in the example of Figure 23, through the use of the registry 8, the contractor can simply install the agent device, scan the code using simple means such as plugging in the power supply or pressing a single button, and / The work of the contractor installing the equipment is simplified and the registry 8 then authenticates the agent device and establishes a connection with the application providing device 6. [ The contractor does not have to spend time interacting with the user interface to configure the agent device.

While specific embodiments have been described herein, it will be appreciated that the invention is not so limited, but many modifications and additions may be made within the scope of the invention. For example, various combinations of the features of the following dependent claims may be made with the features of the independent claims without departing from the scope of the invention.

Claims (31)

An agent device registered in a first device registry maintained by a first registry apparatus for authenticating agent devices for communicating with one or more first application provision devices, To a second device registry maintained by a second registry device for authenticating agent devices for communicating with the second application providing device, wherein the first device registry stores an identity of the agent device Comprising: first authentication information for authenticating a user;
(a) the first registry device receiving a device allocation request from a requestor device requesting that the agent device be assigned to the second device registry;
(b) in response to the device allocation request, checking whether the first registry device is allowed to be assigned to the second device registry in response to the device allocation request from the requestor device ;
(c) if the agent device is permitted to be assigned to the second device registry, sending the second authentication information for authenticating the identity of the agent device to the second registry device; And
(d) the second registry device registers the second authentication information for the agent device in the second device registry
≪ / RTI > 2. The method of claim 1, wherein the second authentication information is the same as the first authentication information. 2. The method of claim 1, wherein the second authentication information is different from the first authentication information. 4. The method of claim 3, wherein the agent device comprises authentication information generation circuitry for generating the second authentication information. 5. The method according to any one of claims 1 to 4, wherein the first registry device is operable to determine from the first device registry that the agent device is allowed to be assigned to the second device registry, And deletes the first authentication information for the first authentication information. 2. The method of claim 1, wherein the first authentication information includes a first public key corresponding to a first private key maintained by the agent device, And a second public key corresponding to the key. 7. The method of claim 6, wherein the agent device deletes the first private key after transmitting the second authentication information to the second registry device. 8. The method of claim 6 or 7, wherein step (c) comprises the step of the agent device sending a digital certificate containing the second public key to the second registry device, wherein step (d) And the second registry device signing the digital certificate. 9. The method according to any one of claims 1 to 8, wherein if the agent device is allowed to be assigned to the second device registry, then at least one of the first registry device, the second registry device, Instructs the agent device to send the authentication information to the second registry device. 10. The method of any one of claims 1 to 9, wherein if the agent device is allowed to be assigned to the second device registry, then at least one of the agent device and the first registry device performs an atomic operation, Wherein the atomic operation comprises at least one of generating information corresponding to the second authentication information and deleting information corresponding to the first authentication information. 11. The method of any one of claims 1 to 10, wherein the requestor device comprises the second registry device. 12. The method according to any one of claims 1 to 11, wherein checking whether the agent device is allowed to be assigned to the second device registry comprises: authenticating the requestor device by the first registry device / RTI > 12. The method according to any one of claims 1 to 11, wherein checking whether the agent device is allowed to be assigned to the second device registry further comprises: if the first registry device determines that the requestor device is already authenticated Checking if the device is a trusted device. 14. The method according to any one of claims 1 to 13, wherein checking whether the agent device is allowed to be assigned to the second device registry comprises: checking whether the agent device is allowed to be assigned to the second device registry, And checking whether the device registry supports allocation to the device registry. The method according to claim 1,
One of the first registry device, the second registry device, and the requestor device sending an address of the second registry device to the agent device; And
And storing the address of the second registry device so that the agent device enables subsequent communication with the second registry device. The method according to claim 1,
(e) the first registry device receiving a reset request to reassign the agent device to the first device registry;
(f) checking whether the first registry device is allowed to reassign the agent device to the first device registry in response to the reset request;
(g) if the agent device is allowed to be reassigned to the first device registry, the agent device sends third authentication information to the first registry device; And
(h) registering the third authentication information in the first device registry by the first registry device
≪ / RTI > 17. The method of any one of claims 1 to 16, wherein the agent device is assigned to the second device registry from the first device registry, without intervention from a user of the agent device. A first registry device for authenticating agent devices for communicating with one or more application providing devices,
A storage device configured to store a first device registry of agent devices, the first device registry comprising authentication information for authenticating the identity of the agent device;
A communication circuit configured to receive, from a requestor device, a device assignment request requesting that an explicit agent device registered in the first device registry be assigned to a second device registry of agent devices maintained by a second registry device; And
In response to the device assignment request, to check whether the specified agent device is allowed to be assigned to the second device registry, and if the specified agent device is allowed to be assigned to the second device registry, A processing circuit configured to control the communication circuitry to indicate to the at least one of the agent device, the requestor device, and the second registry device that the specified agent device can be assigned to the second device registry,
And a second registry device. 19. The apparatus of claim 18, wherein if the agent device is allowed to be assigned to the second device registry, the processing circuit is configured to delete the authentication information for authenticating the identity of the specified agent device from the first device registry , A first registry device. 19. The method of claim 18, wherein, in response to a reset request received by the communication circuit, the reset request requests that a selected agent device registered in the second device registry be reassigned to the first device registry, Wherein the processing circuit checks if the selected agent device is allowed to be reassigned to the first device registry and if the selected agent device is allowed to be reassigned to the first device registry, And register the received authentication information in the first device registry. A first registry device for authenticating agent devices for communicating with one or more application providing devices,
Storage means for storing a first device registry of agent devices, the first device registry comprising authentication information for authenticating the identity of the agent device;
Communication means for receiving a device assignment request from a requestor device requesting that an explicit agent device registered in the first device registry be assigned to a second device registry of agent devices maintained by a second registry device; And
In response to the device allocation request, checking whether the specified agent device is allowed to be assigned to the second device registry, and if the specified agent device is allowed to be assigned to the second device registry, Processing means for controlling the communication means to instruct at least one of the requestor device and the second registry device that the specified agent device can be assigned to the second device registry,
And a second registry device. A method for maintaining a first device registry of agent devices for a first registry device to communicate with one or more application providing devices, the first device registry comprising authentication information for authenticating the identity of the agent device, Way,
Receiving, from a requestor device, a device assignment request requesting that an explicit agent device registered in the first device registry be assigned to a second device registry of agent devices maintained by a second registry device;
Checking whether the specified agent device is allowed to be assigned to the second device registry in response to the device allocation request; And
Wherein if the specified agent device is allowed to be assigned to the second device registry, the specified agent device is assigned to the second device registry to at least one of the specified agent device, the requestor device, and the second registry device ≪ / RTI >
≪ / RTI > A first registry device for authenticating agent devices for communicating with one or more application providing devices,
A storage device configured to store a first device registry of agent devices, the first device registry comprising authentication information for authenticating the identity of the agent device;
Requesting a device assignment to a second registry device for maintaining a second device registry of agent devices, the request requesting that an explicit agent device registered in the second device registry be assigned to the first device registry A communication circuit configured to receive a signal; And
A processing circuit configured to register authentication information received from the specified agent device for authenticating the identity of the specified agent device in the first device registry;
And a second registry device. 24. The apparatus of claim 23, wherein the communication circuit is configured to send a reset request to the second registry device, wherein the reset request is a request for a selected agent device currently registered in the first device registry And to be reallocated to the second device registry to be maintained. A first registry device for authenticating agent devices for communicating with one or more application providing devices,
Storage means for storing a first device registry of agent devices, the first device registry comprising authentication information for authenticating the identity of the agent device;
Requesting assignment of a device to a second registry device for maintaining a second device registry of agent devices, the request requesting that an explicit agent device registered in a second device registry be assigned to the first device registry ≪ / RTI > And
Processing means for registering in the first device registry authentication information received from the specified agent device for authenticating the identity of the specified agent device
And a second registry device. A method for maintaining a first device registry of agent devices for a registry device to communicate with one or more application providing devices, the first device registry comprising authentication information for authenticating the identity of the agent device, ,
Requesting a device assignment to a second registry device for maintaining a second device registry of agent devices, the request requesting that an explicit agent device registered in the second device registry be assigned to the first device registry ;
Receiving authentication information from the specified agent device; And
Registering the authentication information received from the specified agent device in the first device registry
≪ / RTI > An agent device for communicating with one or more application providing devices,
A processing circuit configured to perform authentication with the first registry device based on first authentication information registered for the agent device in a first device registry maintained by a first registry device;
An authentication information generation circuit configured to generate second authentication information for authenticating the identity of the agent device in response to a device assignment request to assign the agent device to a second device registry of agent devices maintained by a second registry device, ; And
Configured to transmit the second authentication information generated by the authentication information generation circuit to the second registry device to register the second authentication information in the second device registry,
Lt; / RTI > 28. The method of claim 27, wherein the first authentication information comprises a first public key corresponding to a first private key maintained by the agent device, And a second public key corresponding to the key. An agent device for communicating with one or more application providing devices,
Processing means for performing authentication with the first registry device based on first authentication information registered for the agent device in a first device registry maintained by the first registry device;
An authentication information generating means for generating second authentication information for authenticating the identity of the agent device in response to a device assignment request for assigning the agent device to a second device registry of agent devices maintained by a second registry device, ; And
And communication means for transmitting the second authentication information generated by the authentication information generating means to the second registry device for registering in the second device registry
Lt; / RTI > A method for an agent device to communicate with one or more application providing devices,
Performing authentication with the first registry device based on first authentication information registered for the agent device in a first device registry maintained by the first registry device;
Receiving a device assignment request to assign the agent device to a second device registry of agent devices maintained by a second registry device;
In response to the device allocation request, generating second authentication information for authenticating the identity of the agent device; And
And transmitting the second authentication information to the second registry device to register the second authentication information in the second device registry
≪ / RTI > In particular, an apparatus, device, or method substantially as described herein with reference to the accompanying drawings.

Images