KR102169947B1 - Method of establishing a trusted identity for an agent device - Google Patents

Abstract

A trusted identity may be established for the agent device 4 for performing trusted communication with one or more application providing devices 6. The method of establishing a trusted identity includes determining 100 which of the plurality of authentication models is a selected authentication model used to uniquely authenticate the agent device 4. First and second authentication information is generated according to the selected model (102). The first authentication information is for uniquely authenticating the identity of the device, and the second authentication information is for checking whether the agent device has the first authentication information. The first authentication information is embedded in the agent device 4 (104) while the second authentication information is transmitted to the registry apparatus 8 for maintaining the device of the agent devices (106). Authentication model information identifying which is the selected authentication model is also transmitted to the registry 8 (106).

Description

How to establish a trusted identity for an agent device {METHOD OF ESTABLISHING A TRUSTED IDENTITY FOR AN AGENT DEVICE}

The present invention relates to the field of data processing. More specifically, the present invention relates to a method of establishing a trusted identity for an agent device.

Within a home, other building or outdoor environment, there is a constantly increasing number of devices with processing and communication capabilities that allow them to interact with other processing devices. Daily objects and relatively small processing devices can be connected to each other and to a central platform as part of the “Internet of Things”. For example, a sprinkler system in a home may collect information from various humidity sensors and control the operation of the sprinkler based on the humidity information. In addition, healthcare providers may use wireless sensors (eg, heart rate monitors or sensors to monitor whether patients are taking prescribed medications) to track the health of patients at home.

Accordingly, 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 differ 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 data received from the agent device and that the agent device can trust any commands received from the application providing device. However, since many agent devices in the Internet of Things have little processing power, it may be difficult to provide resources to the agent device to establish a trusted relationship with the application providing device and may significantly increase the cost of the agent device. The rapid and widespread deployment of these agent devices means there is a desire to make the installation as quick and efficient as possible. This technology attempts to solve these problems.

Viewed from one aspect, the present invention provides a method of establishing a trusted identity for an agent device for performing trusted communication with one or more application providing devices, the method comprising the following steps:

(a) determining which of the plurality of authentication models is a selected authentication model used to uniquely authenticate the agent device;

(b) Generating the first authentication information and the second authentication information according to the selected authentication model-The first authentication information is for uniquely authenticating the identity of the agent device, and the second authentication information is the agent device To check whether you have it;

(c) embedding the first authentication information in the agent device; And

(d) transmitting, to a registry apparatus for maintaining a device registry of agent devices, second authentication information and authentication model information identifying which of the plurality of authentication models is a selected authentication model used by the agent device.

The registry device may maintain a device registry of agent devices that can be trusted for communicating with one or more application providing devices. The registry may maintain authentication information for authenticating the agent device. However, the present technology recognizes that one authentication model may not be suitable for all kinds of agent devices. Since some agent devices have high security requirements, the security authentication model may be appropriate for these devices, even though they are relatively expensive to implement. On the other hand, for other agent devices, such as temperature monitors in weather forecasting applications, on the other hand, security may not be so important and the authentication model may simply require that the sensor can be identified and its data is trusted to be valid. have. For these devices, a less secure authentication model may be preferred to save cost. Accordingly, the present technology recognizes that it is useful to provide scalable security capabilities for different agent devices.

Thus, when establishing a trusted identity for an agent device, one of a plurality of authentication models may be selected to be used to uniquely authenticate the device. Then, first and second authentication information may be generated according to the selected authentication model. The first authentication information is information held by the agent device by uniquely authenticating its identity, and the second authentication information is information for confirming whether the agent device has the first authentication information. The second authentication information may be transmitted to the registry device to register in the device registry. The registry apparatus may also be provided with authentication model information for identifying which of the plurality of authentication models is used by the agent device.

In this way, a scalable authentication profile can be set up for an agent device to balance the cost of implementation against the security required for that particular device. Also, by maintaining information identifying which model has been used in the registry, other devices can query the registry to establish a degree of trust for a particular agent device and determine how to use that agent device accordingly. For example, a given security application may choose not to use an agent device whose authentication model falls below certain minimum security requirements. The entire platform provided by the agent device and the registry in which trust is established in this way allows greater confidence in the identity and security of agent devices and their corresponding applications.

In general, different authentication models can provide different levels of security. These different levels of security typically entail different implementation costs. For example, implementing higher security may require the agent device to be provided with certain resources, thereby increasing the cost of manufacturing the device.

Once the selected authentication model has been determined, the method may include providing authentication resources to the agent device to implement the selected authentication model. For example, a trusted identity may be established during the manufacturing process of the agent device, and then, once a model is selected, certain resources may be built into the agent device. For example, a resource may include a protected storage for storing authentication information, or circuitry for generating authentication information, which may be different depending on which model is selected.

As an alternative, a trusted identity can be established once the agent device has already been manufactured with some authentication resource, such as a protected storage or key generation capability. In this case, the selection of the authentication model may be limited to a predetermined degree in which authentication resources are available. Nevertheless, a selection can be made and an indication of which model is the selected authentication model can be provided in the registry.

In some examples, an external device separate from the agent device may generate first and second authentication information, and then the first authentication information may be embedded in the agent device by the external device. For example, the external device may be a computer or other support system operated by the manufacturer or distributor of the agent device. For security reasons, it may be useful for an external device to delete the first authentication information after it is embedded in the agent device, without transmitting the first authentication information to any other device. In this way, the first authentication information may be constrained to only the agent device and other devices may not be able to access it. This reduces the likelihood that another device will pass itself like an agent device using the first authentication information.

Alternatively, the first and second authentication information may be generated internally by circuitry in the agent device. For example, the device may have a key generator capable of generating keys corresponding to the first and second authentication information. This approach may be more secure because the first authentication information has never existed outside the agent device, so no other device can steal the identity of the agent device. However, this approach can increase manufacturing costs as key generation resources need to be provided to the agent device. For example, key generation may require good random number generation to be provided, which can be expensive to implement.

Embedding the first authentication information in the agent device can be performed in different ways. If this method is performed during device manufacturing, embedding may include providing a storage circuit in the agent device in addition to storing the first authentication information. For example, a flash memory or a read-only memory (ROM) may be built in the device to store the first authentication information. Alternatively, if the device has already been manufactured with a storage circuit, embedding may include storing the first authentication information in a storage circuit already provided.

For additional security, the first authentication information may be embedded in a protected storage area of the agent device. For example, only trusted software can read the first authentication information from the protected area, and the first authentication information in the protected area can also be prevented from being overwritten.

Different authentication models can differ from each other in a number of ways. The description below discusses various ways in which authentication models may be different, but it will be appreciated that models may be provided that combine some of the features discussed below if desired.

In some authentication models, the first authentication information and the second authentication information may include the same authentication information. That is, the registry may store a shared key or other authentication information that the agent device also uses to authenticate itself. For example, a symmetric key such as an AES (Advanced Encryption System) key may be used. This approach can be quite inexpensive to implement, but the level of security achieved by this model is because the registry has access to information that uniquely identifies the agent device, and the transfer of this information to the registry can be vulnerable to security breaches. Is reduced.

In other models, a higher level of security can be achieved by providing different authentication information as the first and second authentication information. For example, the agent device may have a private key as the first authentication information and the registry may have a public key different from the private key as the second authentication information. For example, the private key and public key may be an elliptic curve cryptography (ECC) key. This approach is more secure—not exposed to the registry—as only the agent device has access to its private key. The transmitting step may include transmitting the digital certificate including the public key to the registry. For example, the digital certificate may be an X.509 certificate.

Another way in which different authentication models may vary lies in whether the first and second authentication information are mutable or immutable. In some models, the authentication information is immutable, so once a trusted identity has been established for the agent device, the authentication information is fixed and cannot be changed. For example, the first authentication information may be written in an area of the storage that cannot be overwritten, and the agent device may not have any circuitry to regenerate the authentication information once it leaves the manufacturer or distributor. This approach is cheaper to implement, but it is not possible to generate a new key if the agent device's key information is compromised. Nevertheless, compromising a key for one device need not affect any other agent device if the key information is unique to that device. In other examples, several agent devices may share the same authentication information.

On the other hand, in the case of other authentication models, authentication information may be changeable. The agent device may have an authentication information generating circuit for regenerating the first and second authentication information, and the agent device may transmit new second authentication information to the registry device to update the registry entry of the device. With this approach, higher security is achieved because the keys are regenerated periodically to reduce the likelihood of the key being compromised.

Thus, these different attributes can be combined to establish a variety of different authentication models that provide scalable security that is compromised against implementation costs. For example, three authentication models can be established. In the first authentication model, the first and second authentication information contain the same information and may be immutable. In the second authentication model, the first and second authentication information may include different authentication information and may be immutable. In the third authentication model, the first and second authentication information may include different authentication information and may be changeable. They provide different options for the developer of the agent device to select the application provider to use properly.

Another way the authentication models may be different lies in whether they allow the agent device to be reassigned to a different registry once it has already been registered with the first registry. For example, a private organization or government might want to operate a private registry of its own agent devices so that it can more directly control the authentication of devices so that they can avoid being authenticated for use by other organizations. I can. However, supporting secure transfer to another registry may require certain resources to be available, such as the ability to regenerate key information so that the old registry can no longer authenticate the device. Thus, once again, there is a trade-off between supporting reallocation to different registries and the cost of implementing it. Thus, the ability to allocate devices as desired per models may or may not be provided.

When establishing the device identity, the method may also include establishing a device identifier that uniquely identifies the agent device and embedding it in the device. The device identifier may be sent to the registry device to allow the registry device to correlate it with authentication information and any other metadata for the device.

In addition, registry authentication information may be embedded in the agent device to authenticate the registry device. This allows the agent device to check that the registry is valid and trusted.

Further, the method may include embedding a registry address such as a URL or IP address of a registry device. This allows the agent device to contact the registry device for authentication. For example, the agent device may automatically contact the registry device identified by the registry address when it is first activated (eg, the first power-on of the agent device when deployed).

Viewed from another aspect, the present invention provides a registry device for maintaining a device registry of agent devices for performing trusted communication with one or more application providing devices, the registry device comprising the following circuits:

To store a device registry comprising at least one registry entry for a corresponding agent device containing authentication model information identifying which of the plurality of authentication models is a selected authentication model used to uniquely authenticate the corresponding agent device. Configured storage circuit; And

In response to an authentication model query from an external device requesting authentication model information for the specified agent device, a communication circuit configured to transmit authentication model information of a registry entry for the specified agent device to the external device.

By maintaining a registry containing authentication model information that identifies which authentication model has been used for a particular agent device, other devices can query the registry to identify device capabilities. This allows application providing devices to adapt their own operation according to the security available at the agent device. For example, an application provider may avoid interacting with an agent device with an authentication model whose security is not sufficient for the purpose of the application provider.

The registry device may authenticate the agent device, and if the agent device is authenticated, the registry device may transmit application key information to the agent device and the application providing device in order to enable trusted communication between the agent device and the application providing device. Thus, the registry acts as an intermediary for providing the application key so that the agent device itself does not need to do this. This can help simplify the configuration of the agent device, which is useful for devices in the Internet of Things where agent devices, such as sensors, may not have significant processing power.

Viewed from another aspect, the present invention provides a registry apparatus for maintaining a device registry of agent devices for performing trusted communication with one or more application providing apparatuses, the registry apparatus comprising:

Storing a device registry including at least one registry entry for a corresponding agent device including authentication model information identifying which of the plurality of authentication models is a selected authentication model used to uniquely authenticate the corresponding agent device. Storage means for; And

Communication means for transmitting authentication model information of a registry entry for a specified agent device to an external device in response to an authentication model query from an external device that requests authentication model information for the specified agent device.

Viewed from a further aspect, the present invention provides a method for a registry device to maintain a device registry of agent devices for performing trusted communication with one or more application providing devices, the method comprising the following steps:

Maintaining a device registry including at least one registry entry for a corresponding agent device containing authentication model information that identifies which of a plurality of authentication models is a selected authentication model used to uniquely authenticate the corresponding agent device. step;

Receiving an authentication model query for requesting authentication model information for a specified agent device from an external device; And

In response to the authentication model query, transmitting authentication model information of a registry entry for the specified agent device to an external device.

Viewing from a further aspect, the present invention provides a method of registering an agent device in a device registry of agent devices for performing trusted communication with one or more application providing apparatuses, the method comprising the following steps:

(a) determining which of the plurality of authentication models is a selected authentication model used by the agent device to uniquely authenticate the agent device; And

(b) transmitting, to a registry apparatus for maintaining the device registry, authentication model information identifying which of the plurality of authentication models is a selected authentication model for the agent device.

The authentication model information may also be transmitted to the registry device at a later stage after the trusted identity of the agent device has already been established. In this case, the method may include determining which authentication model has been used for the agent device and transmitting authentication model information to the registry apparatus. If authentication information has not yet been sent to the registry, it may also be sent when registering the device with the registry.

Additional aspects, features, and advantages of the present invention will each be described in more detail below with reference to 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 the relationship between an agent device, an application provider, a device registry, and a consumer;
3 shows an exemplary timeline showing the progress of an agent device through its lifetime from manufacturing to use in an application;
4 schematically shows an example of an agent device;
5 schematically shows an example of storage areas provided in an agent device for storing authentication information and other information for establishing communication with the registry apparatus;
6 shows an example of an application providing device;
7 shows an example of a registry apparatus for maintaining a trusted device register;
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 security and the cost of implementing security;
10, 11, and 12 show three examples of authentication models for authenticating the identity of an agent device;
Fig. 13 is a table comparing different attributes of the authentication model shown in Figs. 10-12;
14 shows a first exemplary method of establishing a trusted identity for an agent device;
15 shows a second exemplary method of establishing a trusted identity for an agent device;
Fig. 16 shows a method of performing authentication between an agent device and a registry device and establishing encrypted communication between the agent device and an application providing device;
17 shows an example of how to associate an agent device with a user and associate an agent device with a specific application;
18 shows an example of a method of allocating an agent device currently registered in the first registry to the second registry;
19 shows an example of a method of resetting the ownership of the agent device back to the first registry;
20 to 23 show four examples of use cases of an agent device, a registry device, and an application providing device.

FIG. 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 provides a cloud service, executes an application program using data collected from one or more agent devices 4, and/or issues a command to control one or more agent devices 4 It may include a device of. 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. The agent device 4 may comprise a larger processing device, such as a tablet computer or mobile phone, but often the agent device 4 is limited, such as sensors that collect sensory data and feed it back to the application. It may also comprise a relatively small scale device that performs only a set of tasks, or a relatively simple control unit that controls an associated object such as a sprinkler, pool pump or air conditioning unit. The agent device 4 can communicate with other devices (such as the application providing apparatus 6 and the registry apparatus 8) using wired or wireless communication that can be via an Internet connection. In this 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 sensing.

The agent devices 4 and the application providing device 6 communicate by encrypted communication. In order to assist in establishing such encrypted communication, one or more registry devices 8 are provided for maintaining a trusted agent device registry that stores information about the trusted agent device 4. The registry 8 facilitates automated secure pairing of the agent device 4 with the application providing device 6, so that even if the application and agent devices are provided by different manufacturers, suppliers or distributors, the application is ) And data integrity, and make the agent device 4 trust the authenticity 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 communicating with them and the agent It eliminates the need for the user of the device 4 to perform a configuration operation to establish 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 communicates with a different set of agent devices 4 and application providers 6. As shown in Fig. 1, it is possible for the agent device A8 to be registered in more than one registry. Similarly, the application providing device 6 can communicate with a plurality of registries. In addition, although most of the agent devices 4 communicate with one application providing device 6, it is also possible to configure the registry to communicate the agent device 4 with a plurality of application providers (for example, FIG. 1 Agent device (A2)).

The functions of the agent device 4 and the application providing device 6 may vary considerably for different applications. For example, the agent device 4 may collect weather data to be delivered to the application provider 6 that performs a weather application that performs a forecast based on data collected by the agent device 4. In addition, some agent devices 4 may collect information about the user's fitness program, such as heart rate, frequency frequency, etc., which will be fed back to the health monitoring application maintained by the application provider 6. I can. In another example, the home air conditioning system may include a central monitoring application 6 and a number of agent devices 4 such as temperature sensors, humidity sensors, user configurable panels, and air conditioning control units. The application controls the operation of the air conditioning control unit based on the detection of sensors and user preferences set in the user configuration panel. There are many additional applications that can use the application providing device 6 and 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, policing, asset tracking, and logistics. The registry 8 provides a common architecture for managing authentication and trust between IoT devices and applications 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 set up a user profile of the consumer 10 using a user ID and password. Consumers in this context could be, for example, people, households or companies.

The agent device 4 (for example, a sensor) contains 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 confirm that it is a trusted agent device. Similarly, the registry 8 and the application provider 6 can exchange keys to verify each other's identities and establish a trusted relationship. If the registry 8 establishes trust with both the agent device 4 and the application providing device 6, the registry 8 will provision application keys to both the agent device 4 and the application providing device 6 I can. The application key provided by the registry 8 is then used to encrypt the communication between the agent device 4 and the application provider 6 without any need for communication via the registry 8. Thus, the registry 8 does not require the agent device 4 and the application provider 6 to establish a direct trust between them, and the trusted communication between the agent device 4 and the application provider 6 Facilitates the establishment of This is because the agent device 4 can be a small, ultra-low power device (such as a temperature sensor or heart rate monitor) with little processing power to implement a protocol and cryptographic algorithm for verifying the identity of the application provider 6 useful. In addition, often the person installing the agent device 4 may not have the knowledge or information to perform complex configuration applications to establish trusted communication 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 communication.

Note that in FIG. 2 there is no relationship between the consumer 10 and the registry 8. The registry 8 does not have any details about the consumer, such as a user ID or password, so no personal details are transmitted or stored by the registry. The consumer's relationship 10 is only for the application provider 6. The registry 8 communicates only 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 trusted communication has been established between the agent device 4 and the application 6, the direct communication proceeds between the agent device and the application without involving the registry.

In other examples, there may be no consumer 10 as shown in FIG. 2 and instead the agent device 4 may belong to the same organization that operates the application providing device 6. For example, a smart connected city may have Internet of Things devices around the city for monitoring street lighting, traffic flow, or garbage collection, for example, and the city manager may have an agent device 4 providing sensing data ) And one or more application-providing devices 6 for monitoring and processing the data acquired by the agent device 4 (e.g., the application can be used by a city resident to check the status) And provide a cloud platform that you can access to report issues). In this case, there may be no consumer 10 associated with a particular agent device 4 as shown in FIG. 2. Nevertheless, the use of the registry 8 simplifies the installation of the agent device 4. For example, a contractor installing an agent device 4 in a street lighting 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, upon activation of the agent device 4 (e.g., upon power-up or deployment of the agent device), the agent device automatically communicates with the registry 8 to establish a trusted relationship with the application 6 can do.

3 shows an exemplary timeline showing the progress of the agent device (sensor) 4 from its manufacture until communication with the application provider 6 is established through registration and authentication with the registry 8. In step A, a system on chip (SOC) for the agent device is fabricated from silicon. In step B, an original equipment manufacturer (OEM) and/or an original device manufacturer (ODM) manufactures the agent device 4 using a system on a chip. At some point during manufacture, 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 bureau or city government. During the manufacture of step B or during the distribution of step C, registration information is provided to the registry 8 to register the agent device 4 with the registry 8 as a trusted agent device. The registry 8 may be provided with key information for confirming whether 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 having 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, in 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 a device identifier of some kind, such as a reference number, a barcode or a QR code (Quick Response code). The application provider 6 may provide a web interface or a smartphone or tablet app for inputting a device identifier or scanning a barcode or QR code and uploading the device identifier to the application provider 6 along with the user identifier. Alternatively, this may be performed by the application provider upon registration of the consumer to the application provider and subsequent assignment 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, so that the registry is It now knows whether 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 specific cloud service or application provider 6. Without need, 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 turning on the agent device for the first time. 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 embedded in the agent device 4 in step B and mutually authenticate each other using the key information that was registered in the registry 8 during registration in step B or C to establish trust. do. If mutual authentication is successful, the registry 8 provides the application key to the agent device 4 and the application provider 6, and in step F, the agent device 4 and the application provider 6 are from the registry 8 Secure communication is possible by encrypting and decrypting messages using the received application key. Thus, the registry 8 allows trust to be established between the agent device 4 and the application 6 without requiring the agent device to perform any complex configuration.

In summary, the registry 8 provides an architecture for managing the authentication of trust between the IOT device (eg, sensor) 4 and the application providing device (cloud provider) 6. The registry 8 manages metadata for each application provider 6 and agent device 4, manages the relationship between the agent device 4 and the application provider 6, and authenticates the device identifier. , A cloud platform that provides a key to enable secure communication to agent devices and applications. The agent device 4 is manufactured according to specific design guidelines that ensure that the agent device 4 has a unique authenticable identity, secure key storage, and cryptographic capabilities to secure trust, and predictable platform robustness. And can be designed. The agent device manufacturing support platform may support key generation and insertion into the agent device 4 and management of key pairs, as well as an interface with a registry.

This architecture helps to solve some of the 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. Advantageously, the device identifier can be globally unique so that no two devices throughout the world share the same identifier. This means that the manufacture and assignment of device identifiers can be completely independent of any subsequently used registry. However, it is also possible that the device identifier is locally unique within a given registry or registry population, and the same identifier is 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 secure pairing the agent device for the application, the application trusts the agent device authenticity and the agent device trusts the application authenticity. I can. 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 opens the market for the agent device and the application, so that any application provider to achieve trust. There is no need to use the agent device 4 of a specific brand provided by (6). The application can trust a wide range of agent devices from multiple manufacturers and the agent devices can trust a wide range of applications from multiple providers. This will help reduce the cost of agent devices and applications and also help increase the use of IoT agent devices and applications. In addition, the registry 8 helps to increase the reliability of the application provider for 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 "little data" collected by the individual agent device 4. If the cloud service cannot trust its individual agent device 4, then the conclusions obtained by "big data" cannot also be trusted, making the whole application meaningless. This technology helps to maintain confidence in the overall information collected by these applications. In addition, the registry 8 may store other information such as agent device characteristics and a usage history of the agent device 4. This can be used to allow the application provider 6 to target a specific kind of agent device 4. For example, the application 6 may only want to collect data from the agent device 4 with certain minimum security requirements.

4 schematically shows the agent device 4. 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 the data required by the application provider 6. The agent device 4 is also used to control various processing operations performed by the agent device 4, such as mutual authentication, encryption of data transmitted to the application providing device 6, and key generation. And a processing circuit 12. The agent device 4 also has a communication circuit 14 for communicating with external devices such as a registry device 8 and an application providing device 6. The communication circuit 14 is communication using a wireless local area network (WiFi), short-range communication such as radio frequency communication (RFID) or near field communication (NFC), or communication used in a wireless sensor network such as Zigbee or Bluetooth or 6LoWPAN. Of, wireless communication can be used. Further, the communication circuit 14 may 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 circuit 14 may also use two or more different forms of communication, such as examples in 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.

4 shows an example in which the agent device is a sensor including the sensing circuit 11, but in other examples, the sensing circuit 11 may not be essential. Instead, for example, the agent device may comprise a control circuit for controlling a physical object such as, for example, a sprinkler, a burglar alarm, a heating or air conditioning unit, or a traffic light system.

5 schematically shows an example of information stored in the storage circuit 16 of the agent device 4. 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 manufacture of the agent device 4. In this embodiment, once fixed to the OTP area 20, the device identifier 22 cannot be changed. For example, after writing the device identifier to the OTP area 20, a fuse may be burned in the storage circuit so that the OTP area 20 cannot be rewritten. As an alternative, some devices can generate a new identifier for post-device manufacturing. For example, when transferring a device to a different registry, it may be possible to assign a new identifier to that device in order to avoid conflict with the identifiers of devices already being managed by the new registry.

The storage circuit 16 also has a nonvolatile memory area 24 that can be read and written, but with read and write protection applied and accessible only by privileged software executed by the processing circuit 12. Include. The read/write protected area 24 stores a registry address 26 containing 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 authenticated (registry public key 27). Corresponds to the registry private key maintained by the registry).

The protected area 24 also stores a sensor key 28 or a private key 29, which is a unique key held 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 can 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 a trusted agent device. So the device is authenticated accordingly. As an alternative, 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 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 can be placed in a write protected but not read protected area 34 of the storage circuit 16. Thus, the public key 32 can be read by any device or by any software running on the agent device 4. Further, 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 contains 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 this certificate to authenticate the agent device identity. 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 that 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 carrying out trusted communication with the application provider 6. These keys are provided by the registry 8 and used 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 devices 4 and application providers 6 are provided by the registry 8 to maintain the security of communication between 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 the registry from another device such as a hardware key generator or a key storage device.

6 shows an example of the application providing device 6. A communication circuit 40 is provided for communication with the registry 8 and the agent device 4. Once again, different types 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 that stores various data and applications used by the application providing device 6. For example, the storage circuit 42 uses the data received by the communication circuit 40 from the agent device 4 and processes it in a predetermined manner, or gives a control command to the agent device 4. You can save the program. A processing circuit 44 is provided for executing applications and controlling 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 a secure memory in the storage circuit 42 and a cryptographic algorithm or a secure processing function in the processing circuit 44 may be provided.

7 shows an example of a registry apparatus 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 use various types of wired or wireless communication discussed above. The registry also has a storage circuit 52 for storing programs executed by the registry 8 and for storing a device registry for tracking information about the various agent devices 4 and corresponding applications 6. Execute the application program stored in the storage circuit 52, 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, etc. A processing circuit 54 is provided for controlling the operation of. Once again, encryption features such as a secure memory in the storage circuit 42 and a cryptographic algorithm or a secure processing function in the processing circuit 44 may be provided. The registry 8 can also respond to queries from external devices for information about a given agent device 4, such as information on which authentication model is used by the agent device. For security reasons, not all registries 8 may allow such queries. 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 before responding with information on the agent device 4 to ensure that only trusted querying devices are allowed to obtain this information.

8A shows an example of a registry entry 60 stored by the storage circuit 52 of the registry device 8. Each agent device 4 registered in the registry is a registry entry 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). Can have The registry entry also contains the device certificate 36 and public key 32 of the agent device 4 and other authentication information used by the registry 8 to verify that the agent device 4 is trusted. . Although Fig. 8A shows an example with a certificate 36 and a public key 32 in the same field, they may also be provided in different fields. In addition, registry entry 60 may have fields for different types of authentication information for use in different authentication models.

The registry entry 60 also includes one or more application identifiers 62 that identify one or more application providing devices 6 for which the agent device 4 wishes to establish trusted communication, and the identified application providing devices 6. It contains one or more application keys 30 for communication. Once again, the application identifier 62 and the corresponding application key 30 may be in the same field or separate fields of the registry entry 60. The application identifier may be stored in a 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 simply sends the encrypted data using the application key 30 without worrying about where the data is going. Can be printed.

The registry entry 60 also contains authentication model information that identifies which authentication model the agent device 4 uses to securely authenticate itself, as described below. It will be appreciated that the registry entry 60 may contain many different types of information and metadata about the agent device that can 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 other than those shown in FIGS. 4, 6, and 7.

The registry entry 60 also includes a signature/hash field 68 that contains a trusted signature or hash value generated based on information of at least some of the other fields of the registry entry 60. This allows tamper 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 recalculate the signature or hash using the other fields and check if 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 other embodiments, may be provided as a separate record associated with the registry entry 60 by the device ID 22. . The event entry 69 provides historical information on events that may occur in the corresponding agent device 4. A particular agent device 4 may have 0, 1, or multiple event entries 69 associated with it. Thus, there may be a one-to-many relationship between the registry entry 60 for a particular device and the 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, and the registry entry 60. Includes fields for a signature/hash field for tamper detection similar to the signature/hash field 68. When an event associated with the agent device 4 occurs, a new event entry 69 may be created. For example, events that can be recorded include the dispatch of the agent device 4 after manufacture, shipment (location), activation or deactivation of the device, registration of the device by the consumer, and many others. The event entry 69 allows the registry to track the device's history.

As shown in Fig. 9, different types of agent device 4 may have different requirements for security and authentication. In general, the higher the level of security required (e.g., because the data is valuable, personal, commercially sensitive, or because there are health or public safety concerns associated with the use of the data), the more Because complex resources may be required, the cost of manufacturing the agent device 4 is also higher. 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 as all that is required is that the data is authentic and that it can be trusted. On the other hand, for other types of devices used in healthcare or smart cities or telematics, it may 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 to obtain a higher degree of security. Thus, as shown in FIG. 9, a plurality of different trust levels may be established to provide a scalable technique for maintaining authentic device identity for IOT devices. Each agent device 4 may have a specific authentication model selected for it, and the selected model may be indicated in the registry entry 60 using authentication model information 64 as shown in FIG. 8. There may also be a commercial need for devices with similar functionality with authentication models that operate at different security levels. This can be useful to provide different fields of use.

By establishing different agent devices 4 with different authentication models during manufacture or distribution of devices, the registry 8 can divide or divide 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 agent devices with a specific authentication model. Devices can also query the registry 8 to determine the authentication model for the specified agent device 4. For example, a banking application provider may wish to set that the user's existing agent device 4 will meet certain minimum security requirements prior to establishing trusted communication with the agent device 4. Different authentication models can be different in many different ways. For example, some authentication models may use fixed, immutable, authentication information, while others may allow authentication information to be updated using the key generation circuit 18 of the agent device 4. . In the case of a fixed model, the key generation circuit 18 may not need to be provided to the agent device 4, so that the agent device can be implemented more cheaply, whereas in the case of an agent device having key generation capability, when required Since keys can be generated, 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 others use an asymmetric key where the agent device 4 and the registry 8 have different complementary keys. You can use Some models may allow the transfer of an agent device from one registry to another, while others may constrain the agent device 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 an 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 manufacture. 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 manufacturing. To authenticate the agent device 4, the agent device 4 can send a message to the registry 8, part of which is encrypted with the sensor key 28. If the registry 8 can successfully decrypt that part of the message 28 and use a copy of its own sensor key 28 to verify that it is correct, then the authentication of the agent device 4 is successful. For example, a hash can be generated from the message by the agent device 4 and the sensor key 28 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 created. have. If the two hashes match, the agent device is authenticated. The advantage of the first authentication model is that it is a low implementation cost. It is not necessary to provide a public key infrastructure or key generator 18 in the agent device 4. Only AES, or other shared secret method, is required. However, the lower cost comes at the expense of reduced security, as the shared secret gives the attacker complete control of the device or agent device, including changing ownership or accessing data, if compromised. Since the shared sensor key 28 provided in the registry 8 is the same as the sensor key 28 used to authenticate the device, in particular during the distribution 72 of the sensor key from the manufacturing system 70 to the registry 8 The potential to expose the sensor key 28 is greater compared to the use of asymmetric keys. However, since the sensor key 28 is unique for each agent device 4, even if the sensor key is compromised, it will only affect one agent device 4 and not any other agent devices. . Thus, 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 the key from the list authenticates itself by the agent device 4 Can be chosen to 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. Then, the registry 8 may be provided with the 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.

Fig. 11 shows that the authentication information for the agent device 4 is still fixed (immutably), but this time the authentication information includes a second asymmetric key pair including the private key 29 and the public key 32. An example of an authentication model is shown. 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. This is because it can be widely broadcast to other devices without doing so. The asymmetric key pair is such that a message partially encrypted using the private key 29 in a manner similar to that discussed above can only be decrypted using the corresponding public key 32. Thus, if the registry 8 can successfully decrypt the message received from the agent device using the public key 32, it can be assured that the message comes 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 send 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. Key pairs and certificates can contain any type of signed certificate and key pair. For example, ECC (elliptic curve cryptography) keys may be used as a key pair 29, 32, and an X.509 certificate may be used as a digital certificate 36. In this model, the manufacturing device 70 generates a key pair and certificate 36 during manufacturing and embeds them into the protected areas 24 and 34 of the memory as shown in FIG. 11. There is a potential vulnerability in that the manufacturing process 70 will know the private key 29 of the agent device 4, but the manufacturer 70 will, once the private key is injected into the agent device 4, the private key (29) can be deleted, after which the agent device 4 will be the only device that has access with 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 only requires the transfer of the public key 32 and certificate 36 and not the private key 29. . However, in this model, as the agent device requires more protected memory to store the PKI capability and private key 29, public key 32 and certificate 36, it is costly compared to the first authentication model. Increases. However, the security is higher because there is no permanent shared key known by devices other than the agent device 4. Once again, rather than a single key pair, the agent device 4 can have a list of key pairs available for selection once the agent device has been operated. Nevertheless, since in this case the list of agent devices maintained by the registry 8 consists only of public keys and certificates, the list does not have significant protection requirements. Any known PKI scheme can be used for the second model.

Figure 12 shows a third authentication model that is more secure than the first and second models, but more expensive to implement. Once again, the private key 29 and the public key 32 are provided together with the digital certificate 36 to the storage circuit 16 of the agent device 4. However, the third model differs from the second model in that the on-chip key generation circuit 18 is provided to the agent device 4 to generate the key pairs 29 and 32. This provides more security since the manufacturer 70 never knows the private key 29 of the agent device 4. Also, since on-chip key generation facilities are 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 a read/write protected area 24 of memory. Only the privileged code accesses the private key 29. The on-chip key generation circuit 18 also generates a certificate 36 and transmits a certificate signing request including the device ID 22 and public key 32 to the registry 8. The public key 32 and certificate 36 are also written into the write-protected area 34 of a fully readable memory without protection. The registry 8 verifies that the agent device is authenticated by signing the certificate 36. This method does not have the exposure vulnerability of models 1 or 2 in which the sensor key 28 or private key 29 can be extracted from the registry 8 or the manufacturing platform 70. The agent device's private key 29 is never exposed to any device other than the agent device 4. In this case, the strength of security depends on the quality of the key pair by the on-chip key generator 18, and in order to keep this sufficiently secure, to support secure key generation (e.g., good random number generation will be required). The need for additional silicon adds cost to device manufacturing.

In the example of FIG. 12, the third authentication model also allows a 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 an on-chip key generation circuit 18, this is when the agent device trust is transferred from the first registry 8 to the second registry 80, a new key is generated and 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 certain agent devices to be transferred to that registry and all ties with the public registry 8 be removed. It can be useful for Alternatively, the first registry can be instructed to delete the relevant entry so that the agent device can no longer be authenticated. In this way, the agent device does not need to generate a new key. In yet another variation, the agent device may have more than one pre-stored key. Upon registry change, the previously unused keys can be used.

It will be appreciated that it may also be possible to provide the ability to transfer trust between registries for the other models of FIGS. 10 and 11. However, in this case, since the agent device cannot regenerate its 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, 80 can share the same agent device 4, so that the same agent device 4 can be registered in both registries. Thus, rather than transferring agent device data directly to another registry, instead, an agent device can be assigned to both registries to enable the agent device to communicate with the application providers associated with both registries.

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

14 shows a first example of a method of establishing a trusted identity for the agent device 4. During manufacture of the agent device, during its distribution, or later upon registration of the device into the registry, a trusted identity may be established. In 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 (e.g., if the agent device does not have an 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 agent device manufacturing, any authentication model can be chosen and implement that model (such as building a protected storage, PKI infrastructure, or key generation capability into the device). The processing resources required to do so can be implemented later.

In 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 model selected. In step 104, the device ID 22, the shared sensor key 28 or private key 29, the registry address 26 and optionally the device certificate 36 are transferred to the storage circuit of the agent device 4 ( 16). The embedding step may be implemented by building the storage circuit in the device, or by storing the information in a storage circuit already provided in the agent device during a previous stage of manufacture. The sensor key 28 is embedded if authentication model 1 is used, whereas if authentication model 2 or 3 is used, the private key 29 and certificate 36 are stored in the storage circuit 16. At this time, the agent device 4 may also be provided with registry authentication information for verifying the identity of the registry 8.

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

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 allowing on-chip key generation is used by this sensor 4. In step 120, the sensor 4 sends a registration (listing) request to the registry 8 specifying the device identifier 22 of the sensor 4. In step 122, the registry checks whether sensor 4 is already owned by the registry, and if so, the method ends.

If the agent device is not already owned, in 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 It is placed in a protected storage area 24. In step 126, a certificate signing request is generated and transmitted to the registry 8. The certificate signing request requests that the registry 8 sign the digital certificate 32 of the sensor 4. The certificate contains at least the device identifier 22 of the sensor 4 as the target name, the security level of the sensor 4 (authentication model information), and the public key 32 generated by the key generator 18. In step 128, the registry 8 signs the certificate to verify 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.

Fig. 16 shows a method of performing authentication of the agent device 4 to check whether it is registered as a trusted device, and establishing trusted communication between the agent device 4 and the application providing device 6. The agent device 4 is already registered in the registry 8 using the method shown in Fig. 14 or 15, for example, and thus, the registry 8 has the agent device 4 It is assumed that it contains information for confirming whether it contains authentication information that uniquely identifies it. In this example, authentication model 3 is used so that the agent device 4 contains the sensor private key K _{s .pr} and the registry 8 contains the sensor public key K _{s .pr} corresponding to the private key K _{s .pr .} Contains _pu . Similarly, the agent device 4 has a registry public key K _r. corresponding to the registry private key K _r.pr held by the registry 8 _. You can use _pu to authenticate the registry (8).

In 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 typically not be repeated for each agent device 4 wishing to communicate with the application provider 6. Mutual authentication 150 may be accomplished using any known authentication technique.

In step 152, the agent device is activated, and in response to the activation, the agent device 4 sends an authentication request 154 identified by the registry URL 26 embedded in the protected repository 24 of the agent device. Transfer to the registry. The authentication request includes a device ID 22 that identifies the agent device 4. Activation of the agent device may include, for example, that the agent device is powered on for the first time after installation, or that an activation button on the agent device is pressed. 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 be required to trigger authentication. This means that the person installing or using the agent device does not need to know if the agent device is authenticated. In response to the authentication request 154, the agent device 4 and the registry 8 perform mutual authentication 156 using keys already exchanged by the agent device 4 and the registry 8 during registration or registration. Start. In mutual authentication, the agent device 4 encrypts the hash of the message using the sensor private key K _{s .pr} , and transmits 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 transmits the partially encrypted message 159 to the agent device 4. The agent device 4 obtains a hash of its own message 159, and it obtains a hash of the registry public key K _r. The hash encrypted with _pu is compared with the hash obtained by decrypting it. If the two hashes match, the registry 8 is assumed to be authentic. Similarly, registry 8 obtains a hash from message 158, and this is done with the sensor public key K _{s .} The encrypted hash received with the message 158 is compared with the hash obtained by decrypting it using _pu . Once again, if the two hashes match, the agent device 4 is authenticated.

16 shows separate authentication request 154 and authentication message 158 sent by the agent device 4, but in another embodiment, authentication request 154 and authentication message 158 are the same message. Thus, the agent device 4 transmits a partially encrypted authentication message 158 (along with the device ID 22) to the registry 8 upon activation 152, which allows the registry 8 to mutually authenticate ( 156).

If the registry 8 successfully authenticates the message 158 received from the agent device 4, in step 160 the registry 8 generates an application key 30 and transfers this application key to the agent device 4 Transfer to. In addition, the registry 8 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. Is transmitted to the application provider (6). The registry 8 also transmits the agent device ID of the agent device 4 to the application provider 6, so that any agent device 4 communicates with the application provider 6 using the received application key 30. Let them know if they will do it.

If the agent device 4 successfully authenticates the registry 8, in step 170 the agent device 4 and the application provider 6 are encrypted using the application key 30 received from the registry 8. Initiate communication. If the registry 8 has not been successfully authenticated by the agent device 4, the agent device 4 does not participate in any encrypted communication using the application key 30. In encrypted communication 180, generally the agent device 4 will send data to the application provider 6 and the application provider will send the command to the agent device 4, but sending data or commands in the opposite direction is also possible. It could be possible too. In step 190, the application running on the application providing apparatus 6 processes 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 can be accessed via 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 in the agent device 4. This means that the agent device 4 is very simple and does not need to have complex processing resources, while security can still be maintained.

FIG. 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. In 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, the agent device 4 or the box for the device 4 can print the device ID on its surface and the consumer can read the device ID from the agent device case. Further, the device ID may be expressed as a barcode or QR code or similar graphic representation, and the user may obtain the device ID 22 by scanning the code using a code reader. Then, the consumer 10 transmits a device association request 210 including the consumer's identifier (user ID) and the device identifier 22 to the application provider 6. This step may occur automatically in response to reading a barcode or QR code, for example 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 also links the application identifier of the application provider 6 to the device ID 22 from the agent device association request 210. ) Can be transferred 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 having the device identifier 22 specified by the application association request 220.

In another example, the consumer 10 may have acquired the agent device 4 directly from the application provider, so 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, since there is no need for the device association request 210, the application provider 6 may generate an application association request 220 to be transmitted to the registry 8 using its internal record instead. Note that the registry 8 does not receive user identifiers. The registry entry 60 identifies the agent device 4 only by device ID and does not contain any user data.

In a similar manner, the application association request 220 can 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 is in this case the agent device itself (for example, when the user chooses to switch the application provider), the old application provider 6 previously associated with the agent device 4, the application association The request 220 may come from a variety of sources, including a new application provider 6 to which the device is assigned, or other third party devices. The registry 4 can check whether the device making the application association request 220 is a trusted device before allocating the agent device 4 to the new application provider 6. As an alternative, if the agent device 4 is allowed to be associated with a plurality of application providers 6, it does not replace the previous application provider 6 as in the example given above, but with the previous application provider 6 Together, a new application provider 6 can be registered for the agent device 4.

18 shows a method of allocating the agent device 4 registered in the first registry 8 to the second registry 80. In step 250, the requestor device requests to transfer ownership of the registered agent device 4 to the second registry 80. The requestor device may be the agent device 4, the 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 registered, the method ends. Therefore, in order to be assigned ownership of the agent device, it is necessary to request permission from the first registry 8 currently holding the registration of the agent device. This ensures that only the registry that has already established trust with the agent device can authorize the transfer of its trusted state to another registry 80.

In step 270, the first registry determines whether to trust the requester device that made the agent device assignment request. If you don't trust, the method ends. The first registry may have already authenticated the requestor previously, in which case the requestor may be determined as a trusted requester. Alternatively, in step 270, the registry may newly authenticate the requestor if the requestor has not already been authenticated. The authentication between the first registry 8 and the requestor can be conducted using any known technique. In addition, in the case of some authentication models, the assignment of the agent device 4 to a different registry may not be allowed, so the registry may check whether the authentication model information for the agent device allows the assignment of the agent device.

Following the check at step 270, the agent device is allowed to be transferred to a different registry if the registry trusts the requester, and the method proceeds to step 280, where the agent device 4 is the key generator 18 To generate a new key pair. The agent device 4 can be triggered to generate a new key pair in different ways. In one example, the first registry 8 may instruct the agent device 4 to be assigned to another registry, and in response to this instruction the agent device may generate a new key pair. As an alternative, the first registry 8 may notify the requestor device or the second registry 80 that the device may be assigned, and the device may then trigger the agent device to generate a new key pair. . In 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 secure storage. The certificate signing request is sent to the second registry 80, and in step 300, the second registry 80 signs the certificate and registers the agent device 4 in its device register. In step 310, the agent device invalidates its original registry ownership by deleting the private key 29 from the original key pair and updating its 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 has correctly transferred its registry ownership, and then tells the second registry 80 that the agent device 4 now has ownership of the second registry 80. Be informed that you are under. 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. As an alternative, the entry for the agent device may stay in the registry because the public key 32 from the original key pair is no longer appropriate because its corresponding private key has been deleted by the agent device 4.

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

The agent device 4 or the first registry 8 may take steps to ensure that steps 280 to 320 occur automatically but it is not possible for the steps to be interrupted in the middle and remain incomplete. This is, in the event of a failure in the middle of the update process, the only possible result is that the agent device 4 retains its original key pair and certificate and is not sent to the second registry (following step 270). (Similar to the case where the registry determines that the requestor is not trusted), or the agent device is completely updated so that it is under ownership of the second registry. This ensures that the agent device 4 can always be in contact with one registry (8 or 80) and cannot end without being authenticated by either registry (8, 80).

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 is an application provider to be associated with the agent device 4 ( It is possible to wait for an application association request 220 from an external source indicating the application identifier of 6). As an alternative, upon switching of the registry, the application associated with the agent device 4 can remain the same and the second registry 80 is simply the same as that which was registered for the agent device 4 in the first registry 8. It is possible to register the application identifier(s) (eg, the first registry 8 may provide the application identifier(s) to the second registry 80).

19 is a method for resetting ownership of the agent device 4 previously transferred to the second registry 80 so that the ownership is returned to the management of the first registry 8 to which the agent device 4 was originally registered Shows. In step 350, the second registry 80 (the requester 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 includes performing authentication, checking whether the requestor has been previously authenticated, or determining whether the agent device 4 supports being reset 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 the registration of the device 4 so that it is reset to the first registry 8.

If the agent device is owned by the second registry 80, a new key pair is generated by the agent device 4 in step 380. In step 390, a certificate signing request is prepared with a 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 secure storage 16 of the agent device 4. In step 400, the first registry 8 signs the new certificate to authorize the agent device once more. In step 410, the agent device withdraws its registration with the second registry 80 by deleting the previous key pair and certificate and updating its registry URL 26 to correspond to the first registry 8. In step 420, the device ownership status is updated within the first registry 8 and the second registry 80 can delete its entry for the agent device 4. Then, this method ends. Once again, the operations in steps 380-420 are performed automatically to ensure that the agent device is always registered in one of the registries and cannot be terminated without valid registration in either registry.

The methods of Figures 18 and 19 allow an agent device to be transferred between registries or assigned to multiple registries at a time, which allows some operators to authenticate their agent devices to other agent devices using a public registry. It can be useful to allow providing a private registry of their own agent devices to separate them from. For example, defense agencies, governments, or city managers can maintain their own registry of secure and trusted agent devices for use within the organization. A general public registry can be provided for general use. Once the agent devices are manufactured they can be initially registered in the public registry, but when a change of ownership 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. Preferably, new authentication information can be created upon transfer to a different registry to ensure that the agent device can no longer be authenticated by the old registry.

20 to 23 show four examples of timelines describing different applications for the present technology. FIG. 20 shows a first example of a personal healthcare field in which an agent device (sensor) is tethered to a specific cloud application and provided directly by an application provider and cannot be used in other applications. The agent device 4 is, for example, a wrist-worn sensor comprising a heart rate monitor capable of feeding back heart rate information to an application providing device 6 operated by a healthcare provider to monitor the health of a patient. I can. In step (1), the chip IP company designs hardware and software for the sensor 4 and security design guidelines for the sensor. System-on-chip (SOC) manufacturers create SOCs that contain secure hardware and unique device identifiers. The original device manufacturer (ODM) manufactures the sensor device. The original equipment manufacturer (OEM) develops the final product. At some point during the manufacturing process (which may be the SOC, ODM, or OEM stage), in step 2, the device identifier and 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 identifier, public key, and authentication model information. The registry device 8 registers this information in its device registry.

In step 4, the sensor is sold to a 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 ID of the user. In step 4 or 5, the OEM or application provider 6 provides an application association request to the registry 8 to inform 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 the device will communicate with the application providing device 6 corresponding to the healthcare company when the agent device 4 is activated.

In step 6, the user receives the sensor 4 from the healthcare provider 6. The user adjusts the cuff to fit his wrist, and turns on the sensor 4 to start using it. Turning on the device triggers the sensor 4 to contact the registry 8 with an authentication request, and mutual authentication takes place as described above. The user does not know 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, in 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 an authenticated valid device ID. In step 8, the healthcare provider 6 requests an application key for secure communication with the sensor 4. In step 9, the registry provides the application key 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 healthcare provider 6 without the involvement of the registry.

FIG. 21 is another example of a use case where an agent device may be tethered to a cloud application prior to being provided to the user, instead of a user purchasing a "off-the-shelf" device and later associating the device with a specific cloud application Shows. This allows users to use different types or brands of sensors in the same cloud application. Once again, this example relates to personal healthcare in which the application providing device belongs to a healthcare company. Steps 1-3 are the same as in FIG. 20. 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 attached to the application provider 6.

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

FIG. 22 shows a third use where the “buy your own device (BYOD)” sensor 4 is purchased by the user and the user is free to choose one of several different application providers to use with the sensor 4 Show an example. The Internet of Things (IOT) app store 400 is used to make this selection. Steps 1-4 of FIG. 22 are the same as those of FIG. 21. Once again, the sensor 4 is sold to a retailer and the retailer sells it to an end user. In step 5, the user launches the app store 400 on a smartphone, tablet, or computer, and once again, a QR code or similar technique is used to collect the device ID of the sensor 4. In step 6, the app store 400 validates the sensor's device ID with the registry 8. For example, the app store 400 queries the registry 8 to determine the authentication model used by the agent device or other capabilities of the agent device, and prepares a menu of compatible apps that operate with the agent device 4 can do. The user is provided with a menu of apps, selects the desired app, runs it, and logs in. In step 7, the app store updates the registry at the user's selection so that the registry associates the sensor's device ID with the application identifier of the selected application. The App Store also transmits the sensor's device ID and user ID to the selected application provider 6 so that the provider 6 can link the user ID and sensor ID together. At this point, the registry 8 knows which application a particular sensor 4 will communicate with, and the application provider knows which customer is associated with that sensor 4. Then, steps 8-12 of FIG. 22 are the same as steps 7-11 of FIG. 21, respectively, where mutual authentication between the sensor 4 and the registry 22 is performed, and then , 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 not in personal healthcare, but in large-scale industrial or government deployments. In this example, the agent device feeds back data about the operation of the street light to the cloud platform, and then the maintenance provider uses it to determine, for example, if the street light requires repair ( 4). Steps 1-3 are once again the same as in FIGS. 20 to 22. In step (4), a product comprising a sensor is manufactured and provided to a contractor. For example, a street lamp may be manufactured with integrated sensors, or alternatively, a product comprising the sensor may be manufactured separately from the street lamp for installation on the street lamp at a later stage. At this time, the registry is updated to reflect the sale of the sensor 4 to a specific service provider 6, or as an alternative, the contractor scans the product ID using a smartphone app or similar device, or GPS When providing the location data, it can be done later in the installation of the sensors and street lights in step 5. In step 6, the contractor's device may transmit 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 way, allow the contractor to make an association request linking the sensor 4 to a specific application 6 without the need for the contractor to understand what is being done.

In step 7, upon activation of the agent device 4 (for example, upon power-on), the agent device, such as a street lighting, directly contacts the registry to establish mutual authentication as discussed above. Once authentication is established, in step (8), the registry is used to provide service providers (6) developing or deploying Internet of Things (IoT) based systems where new street lights and agent devices have been installed and are online with a valid authenticated case identity. Is notified. In step 9, the service provider 6 requests an application key for secure communication. In step 10, the registry 8 provides the symmetric application key to the service provider 6 and the agent device itself. Then, direct secure communication is started and the IoT platform of the service provider 6 executes the application using the sensor data provided by the sensor 4. Customers (such as city managers or maintenance contractors) can also access IoT systems using, for example, a web platform (step 11). Thus, in the example of FIG. 23, through the use of the registry 8, the contractor simply installs the agent device, scans the code using simple means such as plugging in a power source or pressing a single button, and/or Since it is possible to activate, the work of the contractor to install the equipment is simplified, and then the registry 8 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 understood that the invention is not limited thereto and that many modifications and additions can be made within the scope of the invention. For example, various combinations of the features of the following dependent claims together with the features of the independent claims may be made without departing from the scope of the present invention.

Claims (29)

A method of establishing a trusted identity for an agent device for performing trusted communication with one or more application providing devices, the method comprising:
(a) determining which of a plurality of authentication models is a selected authentication model used to uniquely authenticate the agent device-the selected authentication model is selected based on the resource of the agent device, and makes the agent device unique The authentication model for seamless authentication indicates reliability for the agent device;
(b) Generating first authentication information and second authentication information according to the selected authentication model-The first authentication information is for uniquely authenticating the identity of the agent device, and the second authentication information is the agent device The step of checking whether to have the first authentication information;
(c) embedding the first authentication information in the agent device;
(d) in a registry apparatus for maintaining a device registry of agent devices, the second authentication information and the selected authentication model in which any of the plurality of authentication models is used by the agent device Transmitting authentication model information for identifying recognition;
(e) receiving, at the registry device, an authentication model query from the at least one application providing device requesting the authentication model information for the agent device;
(f) transmitting the authentication model information for the agent device from the registry device to the one or more application providing devices; And
(g) in the registry device, that the authentication model information for the agent device satisfies a minimum security requirement from the one or more application providing devices and that the one or more application providing devices will perform communication with the agent device. Step of receiving an indication
Containing, method. The method of claim 1,
And the method includes providing authentication resources to the agent device to implement the selected authentication model. The method of claim 1,
Wherein the determining step determines the selected authentication model depending on whether an authentication resource has already been provided to the agent device to implement the selected authentication model. The method of claim 1,
The first authentication information and the second authentication information are generated by an external device separate from the agent device. The method of claim 4,
After the first authentication information is embedded in the agent device, the external device deletes the first authentication information. The method of claim 1,
The first authentication information and the second authentication information are generated internally by circuitry in the agent device. The method of claim 1,
Wherein the embedding comprises providing a storage circuit to the agent device to store the first authentication information. The method of claim 1,
The embedding step includes storing the first authentication information in a storage circuit provided to the agent device. The method of claim 1,
The first authentication information is embedded in a protected storage area of the agent device. The method of claim 1,
The plurality of authentication models includes at least one authentication model in which the first authentication information and the second authentication information include the same authentication information. The method of claim 1,
The plurality of authentication models include at least one authentication model in which the first authentication information includes authentication information different from the second authentication information. The method of claim 11,
For the at least one authentication model, the first authentication information comprises a private key and the second authentication information comprises a public key different from the private key. The method of claim 12,
For the at least one authentication model, the transmitting step comprises transmitting a digital certificate comprising the public key. The method of claim 1,
The plurality of authentication models includes at least one authentication model in which the first authentication information and the second authentication information are immutable. The method of claim 1,
The plurality of authentication models includes at least one authentication model in which the first authentication information and the second authentication information are changeable. The method of claim 15,
Wherein the agent device includes an authentication information generating circuit for regenerating the first authentication information and the second authentication information. The method of claim 1,
The plurality of authentication models,
(i) a first authentication model in which the first and second authentication information includes the same authentication information and cannot be changed;
(ii) a second authentication model in which the first and second authentication information includes different authentication information and cannot be changed; And
(iii) a third authentication model in which the first and second authentication information includes different authentication information and is changeable
Including, the method. The method of claim 1,
Wherein the plurality of authentication models includes at least one authentication model in which the agent device can be reassigned to a different device registry. The method of claim 1,
Wherein the agent device includes a device identifier that uniquely identifies the agent device, and the transmitting step further comprises transmitting the device identifier to the registry device. The method of claim 1,
And embedding registry authentication information in the agent device to authenticate the registry device. The method of claim 1,
The method further comprises receiving, from the at least one application providing device, an indication that the authentication model information for the agent device is less than a minimum security requirement and that the at least one application providing device will not perform communication with the agent device. The method further comprising the step of. A registry device for maintaining a device registry of agent devices for performing trusted communication with one or more application providing devices,
Including at least one registry entry for the corresponding agent device including authentication model information identifying which of the plurality of authentication models is a selected authentication model used to uniquely authenticate the corresponding agent device. A storage circuit configured to store a device registry, wherein the selected authentication model is selected based on a resource of the agent device, and the selected authentication model indicates a reliability of the agent device; And
In response to an authentication model query from an application providing device requesting the authentication model information for a specified agent device, the authentication model information of the registry entry for the specified agent device is transmitted to the application providing device, and the application is provided. A communication circuit configured to receive an indication from an apparatus that the authentication model information for the specified agent device satisfies a minimum security requirement and that the application providing apparatus will perform communication with the agent device.
Including, registry device. The method of claim 22,
Each registry entry includes authentication information for uniquely authenticating the corresponding agent device, and the registry apparatus includes a processing circuit configured to perform authentication of the corresponding agent device using the authentication information. Device. The method of claim 23,
The communication circuit is configured to transmit application key information to the authenticated agent device and the application providing device if the authentication is successful, and the application key enables trusted communication between the agent device and the application providing device. For, registry devices. A registry device for maintaining a device registry of agent devices for performing trusted communication with one or more application providing devices,
Stores a device registry including at least one registry entry for the corresponding agent device including authentication model information that identifies which of a plurality of authentication models is a selected authentication model used to uniquely authenticate the corresponding agent device. Means for, wherein the selected authentication model is selected based on a resource of the agent device, and the selected authentication model indicates a reliability of the agent device; And
In response to an authentication model query from an application providing device requesting the authentication model information for a specified agent device, the authentication model information of the registry entry for the specified agent device is transmitted to the application providing device, and the application providing device Means for receiving an indication that the authentication model information for the specified agent device satisfies a minimum security requirement and that the application providing apparatus is to perform communication with the agent device.
Including, registry device. A method for maintaining a device registry of agent devices for a registry device to perform trusted communication with one or more application providing devices,
Maintaining a device registry including at least one registry entry for the corresponding agent device including authentication model information that identifies which of a plurality of authentication models is a selected authentication model used to uniquely authenticate the corresponding agent device. The step of, wherein the selected authentication model is selected based on resources of the agent device, and the selected authentication model indicates the reliability of the agent device;
Receiving, from an application providing apparatus, an authentication model query for requesting the authentication model information for a specified agent device;
Transmitting the authentication model information of the registry entry for the specified agent device to the application providing apparatus in response to the authentication model query; And
Receiving an indication from the application providing device that the authentication model information for the specified agent device satisfies a minimum security requirement and that the application providing device will communicate with the agent device.
Containing, method. A method of registering an agent device in a device registry of agent devices for performing trusted communication with one or more application providing devices, the method comprising:
Determining which of a plurality of authentication models is a selected authentication model used by the agent device to uniquely authenticate the agent device, wherein the plurality of authentication models provide different levels of security, and the selected authentication model is It is selected based on the resource of the agent device, and the selected authentication model indicates the reliability of the agent device;
Transmitting, to a registry apparatus for maintaining the device registry, authentication model information identifying which of the plurality of authentication models is the selected authentication model for the agent device;
Receiving, at the registry device, an authentication model query from the at least one application providing device requesting the authentication model information for the agent device;
Transmitting the authentication model information for the agent device from the registry device to the one or more application providing devices; And
In the registry apparatus, receiving an indication from the at least one application providing apparatus that the authentication model information for the agent device satisfies a minimum security requirement and that the at least one application providing apparatus will perform communication with the agent device Steps to
Containing, method. The method of claim 27,
And transmitting authentication information for uniquely authenticating the agent device to the registry device. delete

Images