GB2619315A - Mutual trust environment - Google Patents
Mutual trust environment Download PDFInfo
- Publication number
- GB2619315A GB2619315A GB2208046.9A GB202208046A GB2619315A GB 2619315 A GB2619315 A GB 2619315A GB 202208046 A GB202208046 A GB 202208046A GB 2619315 A GB2619315 A GB 2619315A
- Authority
- GB
- United Kingdom
- Prior art keywords
- service
- virtual asset
- asset
- connection
- verification
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000012795 verification Methods 0.000 claims abstract description 98
- 238000000034 method Methods 0.000 claims abstract description 53
- 238000004590 computer program Methods 0.000 claims description 5
- 230000004044 response Effects 0.000 claims description 5
- 230000001419 dependent effect Effects 0.000 claims description 3
- 230000006870 function Effects 0.000 description 24
- 230000009471 action Effects 0.000 description 12
- 238000012360 testing method Methods 0.000 description 10
- 239000003795 chemical substances by application Substances 0.000 description 7
- 230000008569 process Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 4
- 238000005259 measurement Methods 0.000 description 3
- 230000000717 retained effect Effects 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- XUIMIQQOPSSXEZ-UHFFFAOYSA-N Silicon Chemical compound [Si] XUIMIQQOPSSXEZ-UHFFFAOYSA-N 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008635 plant growth Effects 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 238000013442 quality metrics Methods 0.000 description 1
- 238000009781 safety test method Methods 0.000 description 1
- 239000002689 soil Substances 0.000 description 1
- 210000003813 thumb Anatomy 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0281—Proxies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/141—Setup of application sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/562—Brokering proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
- H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/009—Security arrangements; Authentication; Protecting privacy or anonymity specially adapted for networks, e.g. wireless sensor networks, ad-hoc networks, RFID networks or cloud networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0894—Policy-based network configuration management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/14—Network analysis or design
- H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/16—Threshold monitoring
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/126—Applying verification of the received information the source of the received data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/53—Network services using third party service providers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
- H04W12/69—Identity-dependent
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Storage Device Security (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Brokering a trusted connection between two virtual assets in a connection brokerage system is described. The method comprises negotiating a connection between a service-requesting virtual asset 12 and a service-providing virtual asset 10 using two respective verification services 20, 22. A first verification service 20 dynamically verifies if at least one identity-based credential of a controlling entity (e.g. owner A) associated with an external asset (real device A 16) represented within the connection brokerage system by the service-requesting virtual asset, which is received from a component of the registrar computer system 18, matches a corresponding identity-based credential. A second verification service 22 dynamically verifies if at least one credential associated with an external asset 14 represented within the connection brokerage system by the service-providing virtual asset, which is received from a component of the registrar computer system 18 matches a corresponding credential. Only if both verifications are successful do the two virtual assets establish a trusted connection 109. The registrar function may instead be decentralised (Figs 2 & 3) in which case the requesting virtual asset provides instructions to the providing virtual asset on how to verify their identity 210 and vice versa 213. Self-identifying credentials may be used.
Description
MUTUAL TRUST ENVIRONMENT
Background
[0001] The Internet of Things (loT) refers to uniquely identifiable objects in an internet-like structure where the objects are data-enabled and may comprise data sources (e.g. they may be capable of reporting data on a regular, event-triggered or on-demand basis) and/or actuators (e.g. they may be capable of receiving a control instruction and taking an action in response to the control instruction). Equipping all objects in the world with minuscule identifying devices or machine-readable identifiers could transform daily life. For instance, it may improve the growth of plants in a greenhouse by enabling collection of multiple data sources (e.g. air quality inside the greenhouse, weather outside the greenhouse, soil temperature, etc.) and control of watering systems based on the sensed data. However there are a large number of practical challenges in the implementation of loT. These challenges include aspects relating to security of the network, the devices and the data streams and aspects relating to authentication and trust between devices (e.g. a device that provides data and a device that consumes that data). As the number of loT devices increases, the challenges in relation to device discovery and interconnection become more complex.
[0002] The embodiments described below are not limited to implementations which solve any or all of the disadvantages of known systems.
Summary
[0003] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
[0004] Described herein are methods of establishing a mutual trust environment between two virtual assets in a connection brokerage system. Using the methods described herein avoids either virtual asset having to present their own credentials to the other virtual asset. Furthermore, by using third-party verification services, the credentials may be retained in a trusted environment external to the connection brokerage system.
[0005] A method of brokering a trusted connection between two virtual assets in a connection brokerage system is described. The method comprises negotiating a connection between a service requesting virtual asset and a service providing virtual asset using two verification services. A first verification service dynamically verifies if at least one identity-based credential of a controlling entity associated with an external asset represented within the connection brokerage system by the service requesting virtual asset which is received from a component of the registrar computer system matches a corresponding identity-based credential. A second verification service dynamically verifies if at least one credential associated with an external asset represented within the connection brokerage system by the service providing virtual asset which is received from a component of the registrar computer system matches a corresponding credential. Only if both verifications are successful do the two virtual assets establish a trusted connection.
[0006] A first aspect provides a method of brokering a trusted connection between two virtual assets in a connection brokerage system comprising a plurality of service-requesting virtual assets and service-producing virtual assets, the method comprising: receiving, by a registration component of a registration system of the connection brokerage system, a service request from a service requesting virtual asset; determining, based on service descriptors associated with virtual assets held in one or more registration components of the registration system, a service providing virtual asset capable of providing the requested service; and negotiating a connection between the service requesting virtual asset and the determined service providing virtual asset using a first verification service and a second verification service, wherein the first verification service dynamically verifies if at least one identity-based credential of a controlling entity associated with an external asset represented within the connection brokerage system by either one of the service requesting or service providing virtual assets which is received from a component of the registrar computer system matches a corresponding identity-based credential held by a verification service provider, wherein the second verification service dynamically verifies if at least one credential associated with an external asset represented within the connection brokerage system by the service providing virtual asset which is received from a component of the registrar computer system matches a corresponding credential, wherein, if the both verifications are successful and if a connection is successfully negotiated between the two virtual assets by the registrar computer system of the connection brokerage service, the two virtual assets establish the connection as a trusted connection.
[0007] A second aspect provides a system configured to perform any of the methods described herein.
[0008] The methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium. Examples of tangible (or non-transitory) storage media include disks, thumb drives, memory cards etc. and do not include propagated signals. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.
[0009] This acknowledges that firmware and software can be valuable, separately tradable commodities. It is intended to encompass software, which runs on or controls "dumb" or standard hardware, to carry out the desired functions. It is also intended to encompass software which "describes" or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.
[0010] The preferred features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the invention.
Brief Description of the Drawings
[0011] Embodiments of the invention will be described, by way of example, with reference to the following drawings, in which: [0012] FIG. 1 illustrates schematically the data flows within a connection brokerage system when implementing a method of brokering a mutually trusted connection between two virtual assets; [0013] FIG. 2 shows a message flow in a first example of brokering a mutually trusted connection between two virtual assets; [0014] FIG. 3 shows a message flow in a second example of brokering a mutually trusted connection between two virtual assets; and [0015] FIG. 4 shows a message flow in a third example of brokering a mutually trusted connection between two virtual assets.
[0016] Common reference numerals are used throughout the figures to indicate similar 25 features.
Detailed Description
[0017] Embodiments of the present invention are described below by way of example only.
These examples represent the best ways of putting the invention into practice that are currently known to the Applicant although they are not the only ways in which this could be achieved. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.
[0018] As described above, there are a large number of practical challenges in the implementation of loT. As well as problems relating to security, authentication and trust (e.g. where the ownership of different data sources and/or actuators is diverse and/or there are security / safety concerns regarding the data or the actuator control), configuring and managing the large number of deployed devices is difficult, particularly as a consequence of the scale (i.e. the potential number of loT devices that may be deployed). Furthermore, whilst some loT devices may only provide data (e.g. measurement data or other locally generated data), others may include actuators, or control functionality for connected actuators. This means that there is a huge range of capabilities of the deployed devices (e.g. in terms of generating data and/or receiving controls for local actuators).
[0019] In order for an loT device to serve a useful purpose, other devices need to be able to find the loT device and then receive data from the loT device and/or transmit control data to the loT device. A connection brokerage system may be used to broker such connections and in order to broker connections, the connection brokerage system comprises a registrar functionality (which may be implemented as a centralized entity or in a distributed manner) and a plurality of virtual assets. A virtual asset acts as a proxy for a real device (e.g. a physical device such as an loT device that generates data using one or more sensors), a data source (e.g. where the data is not measurement / sensor data), another virtual asset or a group of real devices and/or other virtual assets. Each virtual asset comprises metadata that describes what it is a proxy for (e.g. the real device, data source, group of devices, etc.) along with information about data streams that can be provided by the virtual asset (e.g. wind speed in m/s) and/or can be received by the virtual asset (e.g. on / off or other control signals). Each virtual asset therefore corresponds to a data entry in the connection brokerage system, referred to as a registry entry, that is created when the virtual asset is created. There is a separate agent that corresponds to a virtual asset which drives (or encodes) the behaviour of the virtual asset. The code resides outside the connection brokerage system and may run anywhere (e.g. on a cloud-based server, on the real device itself, or any other computing device located outside the connection brokerage system) as long as it can connect to the virtual asset (i.e. to the data stored in the registry entry for the virtual asset in the connection brokerage system). In this way, the data and code relating to a virtual asset are separate. The agent may act as a bridge between a virtual asset and its corresponding real device (i.e. between the virtual asset and the physical electronics in the device) and may operate to report the state of the real device to the virtual asset and/or to provide a hardware interface to the real device, if the real device is controllable externally (e.g. it comprises or is connected to an actuator). In various examples, there may be an agent that acts as a bridge between each virtual asset and its corresponding real device, although some agents may act as a bridge for more than one virtual asset and/or real device (e.g. there may be fewer agents than virtual assets and/or real devices).
[0020] An loT device registers with the connection brokerage system in order that it can distribute data it generates or in order that it can receive controls for local actuators and on registration, a corresponding virtual asset, and hence registry entry, is created. Such a virtual asset may be referred to as a service providing virtual asset (SP-VA). A device that wishes to obtain data from the system also registers with the connection brokerage system and on registration, a corresponding virtual asset, and hence registry entry, is created. Such a virtual asset may be referred to as a service requesting virtual asset (SR-VA). A physical device may both provide services and request services (i.e. request data and provide control signals) and so may have two (or more) associated virtual assets. In such examples there may be a single agent that acts as a bridge for all the virtual assets associated with a single real device or there may be more than one agent.
[0021] A registrar functionality within the connection brokerage system, which may be implemented as a central server or in a distributed manner, manages the registration of real devices (including identity management), creation of virtual assets and storing and maintaining (e.g. updating when required) metadata about each of the virtual assets in the system. Example registration sequences are shown and described in the following PCT applications W02015/052478, W02015/052479, W02015/052480, W02015/052481, W02015/052482, W02015/052483 and W02015/052512 and registration may involve authentication of the real device and creation of the counterpart virtual asset.
[0022] The registrar functionality also brokering connections between virtual assets (including identity management and global search functionality), i.e. the registrar functionality brokers connections between service requesting virtual assets and service providing virtual assets that are already registered in the system. When a connection is brokered between a service requesting virtual asset and a service providing virtual asset, the service requesting virtual asset subscribes to a data feed or control stream of the service providing virtual asset and dependent upon the nature of the subscription either receives the data stream (i.e. the service requesting virtual asset, or its counterpart real device, receives the data stream from the service providing virtual asset or its counterpart real device) or is enabled to provide control signals (i.e. the service requesting virtual asset, or its counterpart real device, can send control signals to the service providing virtual asset or its counterpart real device). Example methods of brokering connections between virtual assets are shown and described in the referenced PCT applications. Once a connection has been brokered by the registrar functionality, the data (e.g. measurement data or control signals) may be transferred without further involvement of the registrar functionality (i.e. any data transfer does not go via the registrar functionality).
[0023] In a connection brokerage system, such as described above, connections may be brokered between any service requesting virtual asset and any service providing virtual asset.
Alternatively, a connection may be brokered if the service requesting virtual asset has permissions as defined in an access control policy of the service providing virtual asset. In some instances, the service requesting virtual asset may also have an access control policy which specifies one or more criteria for the service providing virtual asset to meet before the connection between the two assets is brokered by the registrar functionality. As described above, the registrar functionality may be centralized or distributed. An example of an access control policy includes an access control list, where this might be defined in different ways, e.g. a list of those that can have access or a list of those that cannot have access.
[0024] For example, the registrar may send a request to the service providing virtual asset to confirm it is okay to provide the requested service which includes details of any credential for the requestor presented in the service request it received. The service providing virtual asset is then able to verify if the credentials presented conform with the conditions for accessing its services set out in the access control policy for the particular service or counterpart real device. The service providing virtual device responds to the registrar affirmatively if the conditions set out in the access control list have been met by the service requesting virtual asset. This may be sufficient for the registrar to indicate to the service providing virtual asset that they should connect to the service requesting virtual asset.
[0025] In some scenarios, however, additional verification (and hence more trust) is required, for example, of the identity of the entity controlling or owning the service requesting virtual asset and/or the service providing asset before a trusted connection between the two assets can be brokered by the registrar functionality. In some examples mutual trust is required. For example, if the service providing virtual asset is the counterpart of a real device (e.g. a railway track actuation switch sensor), it may be important (e.g. for safety reasons) that the identity of the entity controlling/owning the service requesting virtual asset as identified within the connection brokerage system (e.g. in the registry entry for the service requesting virtual asset), is in fact the actual entity requesting to actuate the real device (e.g. the railway switch), and not someone pretending to be the owner. It may also be important (e.g. for safety reasons) for the owner of the service requesting virtual asset to know that they are actually brokering a connection to enable actuation of the real device (e.g. a railway track switch in a railway owned by the correct entity) and not an entity pretending to be the owner of the real device.
[0026] Described herein are methods of establishing a mutual trust environment between two virtual assets in a connection brokerage system. The connection brokerage system comprises a plurality of virtual assets and a registrar functionality that brokers connections between virtual assets. The registrar functionality may additionally perform other functions as described above.
[0027] FIG. 1 illustrates schematically the data flows within a connection brokerage system (such as described above) when implementing a method of brokering a mutually trusted connection between two virtual assets 10, 12. In the example shown in FIG. 1, each virtual asset is a counterpart to a real device (which may also be referred to as a real asset) 14, 16; however in other examples either or both of the virtual assets may not have a counterpart real device. Each real device 14, 16 has an owner which may, for example, be a person or an organisation (e.g. a corporation).
[0028] In the example shown in FIG. 1, the registrar function 18 (which is shown as a cloud to indicate that it may be centralized or distributed) uses credentials for the owner of the real device counterpart 16 of the service requesting virtual asset 12 (owner A) and credentials associated with the real device counterpart 14 (owner / attribute B) of the service providing virtual asset 10 to perform verification with a third party prior to establishing a brokered connection, i.e. the credentials provided are verified by a third party that is separate from both parties involved in the brokered connection and also separate from the connection brokerage system. Furthermore the credentials provided by each party are verified by a different third party verification service. Additionally, as described below, the nature of the credentials shared by each party may be different (in terms of the entity / attribute being verified) e.g. the credentials shared by one party may relate to the identity of the party (owner A) whereas the credentials shared by the other party may relate to an attribute of the real device (attribute B).
[0029] The credentials for the owner of the real device counterpart 16 of the service requesting virtual asset 12 (owner A) may be requested as part of brokering the connection (as shown in FIG. 1 and described below) and the credentials associated with the real device counterpart 14 of the service providing virtual asset 10 (device B) may be retrieved from the registry entry for the service providing virtual asset 10 (e.g. having been provided previously, such as upon registration of the real device with the connection brokerage system) or may be requested from the service providing virtual asset 10 as part of the connection brokering process. The credentials associated with the real device counterpart 14 of the service providing virtual asset 10 may relate to the owner of the real device (e.g. owner B) and/or to attributes of the real device itself (attribute B e.g. test data, calibration data, etc.).
[0030] In FIG. 1, the service requesting virtual asset 12 representing an external service requesting entity (i.e. a real device 16) sends a service request to the registrar function (step 101). The registrar function 18 processes the request and identities a potential service providing virtual asset 10 by matching the service descriptors in the request to those of the virtual asset 10 (e.g. to those stored in the registry entry for the virtual asset 10). External verification services 20, 22 are then used to verify both the owner of the real device counterpart 16 of the service requesting virtual asset 12 (owner A) and credentials associated with the real device counterpart 14 of the service providing virtual asset 10 (owner / attribute B). Whilst these external verification services 20, 22 are shown separately in FIG. 1, in some examples they may be the same external verification service (e.g. where the verification is of owner B rather than attribute B) and in some examples there may be verification of both the owner (owner B) and attributes (attribute B) of the real device counterpart 14 of the service providing virtual asset 10 and this may require two different external verification services (e.g. such that there may be three different external verification services used). An example of a verification service that may be used to verify an attribute is one provided a company performing calibration services or safety checks.
[0031] In FIG. 1, the verification associated with the service requesting virtual asset 12 (i.e. the verification of owner A) is performed first; however in other examples, the verification associated with the service providing virtual asset 10 (i.e. the verification of owner B and/or attribute B) may be performed first, or they may be performed substantially in parallel.
Irrespective of the order in which the verification is performed, the connection brokering process may end without brokering a connection (e.g. be aborted) if any verification fails and the connection is only brokered if all verifications pass.
[0032] As shown in FIG. 1, the registrar function 18 forwards an identifier for the service requesting virtual asset 12 (or its counterpart real device 16 or the owner of the counterpart real device, owner A) to the requestor verification service 20 (step 102). The external verification service 20 determines whether the service requesting virtual asset 12 is trustworthy or not, and this may involve the requestor verification service 20 communicating directly with the real device 16 which is the counterpart to the service requesting virtual asset 12, or with the service request virtual asset 12 as the delegate for the real device 16, to obtain proof (e.g. credentials) to demonstrate the identity of the service requesting party (owner A) and/or that the service requesting virtual asset 12 is associated with that party (steps 103104). The result of the verification of the service requesting virtual asset 12 is communicated back to the registrar (step 105).
[0033] Similarly, the registrar function 18 forwards an identifier for the service providing virtual asset 10 (or its counterpart real device 14, or the owner of the counterpart real device, owner B) to the service provider verification service 22 (step 106). The external verification service 22 determines whether the service providing virtual asset 10 is trustworthy or not, and this may involve the service provider verification service 22 checking data (e.g. authentication data, calibration data, etc.). As described above, the data may relate to an attribute of the real device (attribute B). The result of the verification of the service providing virtual asset 10 is communicated back to the registrar function (step 107).
[0034] If both verification operations are performed successfully, the registrar function 18 establishes a brokered connection between the two virtual assets (steps 108). The two virtual assets 10, 12 can then establish a suitable secure and trustworthy connection which enables the service providing virtual asset 10 to provide a data stream to the service requesting virtual asset 12 and/or to receive commands from the service requesting virtual asset 12, depending upon the nature of the service requested (step 109). As previously described, once the connection is brokered by the registrar function 18, the registrar function plays no part in the provision of the service by the service providing virtual asset 104 to the service requesting virtual asset 12. If either of the verification operations is not successful, then the registrar function 18 does not establish a connection between the two virtual assets.
[0035] Using the method of FIG. 1 avoids either or both the service requesting and/or service providing virtual asset having to present their own credentials to the other virtual asset, but instead these may only be provided to the registrar function 18 or they need not be provided to the registrar function either and instead only an ID and data identifying the external verification service may be provided to the registrar function. By using third-party verification services 20, 22 (i.e. verification services which are separate from the connection brokerage system), the credentials may be retained in a trusted environment external to the connection brokerage system associated with the relevant third party verification service provider. For example, the registrar function 18 can be configured to communicate only the GUID for a virtual asset and an identifier for the entity indicated as owning/controlling that asset to the relevant verification service. The verification service provider can then request credentials and establish trust off-line or dynamically whilst the transaction is being brokered with that entity by performing a challenge/response check of the credentials stored by the verification service provider with those provided by the asset owning/controlling entity, and if the credentials are trusted, may respond with a pass/fail or an indication of the level of trust (e.g. a confidence level that owner A is owner A) to the registrar function 18. Where a level of trust is communicated, the registrar function 18 may determine if this is equivalent to a pass or a fail using a threshold level and the threshold may vary depending upon the nature of the service being requested (e.g. where there are safety or privacy concerns, the threshold that is used may be higher than for other services).
[0036] As shown in FIG. 1, the real device counterpart to the service providing virtual asset (real device 14) is not involved in, and may not be aware of, the verification process. This enables verification of the real device counterpart of the service providing virtual asset (real device 14) to be performed even where the real device does not have network connectivity and hence may be described as a passive (rather than an active) real device.
[0037] Self-identifying credentials may be used in some implementations (for example, of the decentralized registrar system), such as those conforming to the verifiable credentials W3C spec, which also enables trusted connections to be brokered across security domains based on the presented credentials. As described above, the self-identifying credentials may be different (e.g. of a different nature or type) for the two virtual assets (e.g. identity of owner A and attribute of real device B) and as described above, only if both verifications are successful is the brokered connection established.
[0038] The credentials of the service providing virtual asset 10, or its counterpart real device 14, (e.g. attribute B) may be provided in the form of a certificate or some form of metadata for the asset and/or the requested service which enable characteristics such as the identity, condition, operational state, and/or accuracy/quality metrics for performance and/or any information to be provided to be verified.
[0039] In the method shown in FIG. 1, the verification is performed when a connection is brokered. Where the verification of the service providing virtual asset 10 involves verifying an attribute of the real device 14 (in addition to, or instead of, verifying an identity of owner B), then this may need to be re-checked periodically. This may be enabled by time-limiting the brokered connection, thereby forcing the connection to be re-established (and the verification performed again) after the time-limit has expired. The length of the time-limit may be dependent upon the nature of the attribute that is verified and where multiple attributes are verified it may be set based on the attribute that results in the shortest time-limit.
[0040] For example, one type of verification which is performed on real devices is Portable Appliance Testing ("PAT"). PAT is usually performed by a service technician or a similarly authorized person who tests an appliance against certain safety criteria. Passing the test successfully is indicated with a sticker which is fixed to the appliance. In an loT use context, however, if a person wanted to remotely activate an loT appliance or receive a data feed or similar service from it, they would not have any awareness of its PAT certificate status, which is clearly undesirable. The actual portable appliance, even when configured for being controlled remotely, has no record stored in memory indicating a test was performed or the type of test being performed, the result of the test if the test is even passed and a PAT certificate issued or not, never mind when the certificate expires. However, the test itself can be logged in a database, and associated with the serial number of the appliance. Using the method of FIG. 1, the service provider verification service 22 may contain or have access to this database and the verification process (between steps 106 and 107) may comprise interrogating the database using the serial number of the appliance (or other identifier provided by the registrar function 18). In this way, as part of the connection brokering operation, it is confirmed that the appliance is safe to use. The same techniques may in addition, or instead, be used to verify that the real device 14 has been calibrated and/or serviced as required by its manufacturer. This data is again unlikely to be known by the real device 14 itself but may be verified by the service provider verification service 22. The brokered connection may, for example, be set to expire when the test certificate or calibration certificate expires.
[0041] The methods described herein may be used to broker a connection with a loT asset such as a real object or device, without that loT asset itself ever becoming aware of what it is or what service functionality it is providing either as an individual loT asset or collectively with one or more other loT assets, as this knowledge is retained only by the counterpart virtual asset associated with that device in the digital environment.
[0042] FIG. 1 shows the verification being performed when a connection is brokered. In addition, or instead, verification may be performed by the service providing and service requesting virtual assets (instead of the registrar function) each time the service requesting virtual asset provides a command to the service providing virtual asset, as shown in FIGs. 2 and 3. This may, for example, be used where there are safety implications of implementing the command. FIGs. 2 and 3 show schematic diagrams of a method of establishing mutual trust within a connection brokerage system (such as described above). They show two virtual assets -a service providing virtual asset B 202 and a service requesting virtual asset A 204 -and two external (i.e. third party) verification services 206, 208.
[0043] FIG. 2 shows a message flow in which the service requesting virtual asset A 204 is verified by the service providing virtual asset B 202 (arrows 211-212) before the service providing virtual asset B 202 performs the requested command (action #1) and then the service requesting virtual asset A 204 verifies the service providing virtual asset B 202 (arrows 214-215) on receipt of data received from service providing virtual asset B 202 (arrow 213) after the action has been performed (e.g. before the data received from service providing virtual asset B 202 is relied upon in a subsequent action). As shown in FIG. 2, service requesting virtual asset A 204 provides information on how the owner of the service requesting virtual asset A (owner A)should be verified (e.g. in the form of an identifier and details of a verification service or a credential) when it provides the command to the service providing virtual asset B 202 (arrow 210). The service providing virtual asset B 202 provides information on how the corresponding real device (owner / attribute B) can be verified at the same time as providing data indicating that the requested action was completed (arrow 213).
[0044] FIG. 3 shows a message flow in which the service requesting virtual asset A 204 verifies the service providing virtual asset B 202, e.g. verifies owner / attribute B (arrows 321- 322) before it sends the command to the service providing virtual asset B 202 (arrow 323).
This verification may be performed based on information received from its counterpart real device 306 (arrow 320) or information received from another source (e.g. from the registrar function when the connection was brokered). As in FIG. 2, the service requesting virtual asset A 204 is verified by the service providing virtual asset B 202 (arrows 324-325) before the service providing virtual asset B 202 performs the requested command (action #1) and provides confirmation / data to the service requesting virtual asset A 204 (arrow 326).
[0045] In FIG. 2, the verification of the service providing virtual asset B 202 is shown as determining whether the state of B and/or B's data from doing the action (action #1) to be trusted. The verification may therefore relate to attributes of B and/or the owner of B. In FIG. 3, as the verification is performed before the action, the verification is alternatively described as determining whether device B is safe to use. This may involve verifying the state of B and/or another attribute of B or the owner of B. [0046] An example application of the method of FIG. 3 can be described with reference to FIG. 4. In this application, there are two real devices, a sluice gate 400 and a controller 404 which may be remotely located from the sluice gate 400 or may be located proximate to the sluice gate 400 but not directly connected (e.g. via a wire) to the sluice gate 400. Instead, the controller 404 uses a connection brokerage system (as described above) to broker a connection with the sluice gate so that it can operate the sluice gate. Each of these real devices has a counterpart virtual asset 402, 406. As shown in FIG. 4, the controller 404 instructs its counterpart virtual asset 406 to open the sluice gate (arrow 420). The virtual asset for the controller 406 (which is the service requesting virtual asset in this arrangement) performs a verification of the service providing virtual asset (and/or its counterpart, the actual sluice gate) and this verification (arrows 421-422) may involve checking the identity and/or attributes of the sluice gate (e.g. has the sluice gate been serviced according to its manufacturers requirements, is the sluice gate currently operational, etc.). If that verification is passed, the virtual asset for the controller 1406 sends the command to the sluice gate virtual counterpart 402 (arrow 423) and the message sent includes information on how to verify the controller. The sluice gate virtual counterpart 402 uses this information to verify the controller 404 (arrows 424-425) and only performs the action (arrow 426) in response to the verification passing. As shown in FIG. 4, the sluice gate virtual counterpart 420 may receive data from the sluice gate 400 after the action has been performed (e.g. updated status data, confirmation that the action has been performed, etc.) and this may be sent back to the virtual asset for the controller 406 (arrow 428). In this way, the sluice gate is not opened if it is unsafe to do so (i.e. if the verification of the sluice gate fails) or if the controller is not permitted to open it, e.g. because the virtual asset is controlled by a malicious entity, in which case verification of the controller will fail.
[0047] In the examples shown in FIGs. 2-4, the party that is to be verified provides the information about how the verification should be performed. In variations of these examples however, this information may itself be obtained from a third party in order to further increase the security of the system. This third party may be different from any of the verification services used and may act as a repository for verification service information.
[0048] Whilst the methods and systems described above perform two verification operations using two different verification services, in variations of the methods described, more than two verification operations may be performed, each using a different third-party verification service. In such examples, the trusted connection is only established, or the operation performed, if all of the verifications that are performed are successful. Where more than two verification operations are performed the additional verifications (above those described in the examples above) may relate to additional attributes of one of the two entities described above (e.g. a second identity-based credential of the service requesting virtual asset and/or a second credential associated with the external asset represented in the connection brokerage system by the service providing virtual asset). For example, two different attribute-based credentials of the external asset may be verified. These may, for example, relate to two different aspects of the external asset, e.g. its calibration and its safety testing. In other examples, there may be a additional entities involved, e.g. the methods described herein may be used to verify an identity-based credential of the service requesting virtual asset, and both an attributed-based credential and an identity-based credential associated with the external asset represented in the connection brokerage system by the service providing virtual asset.
[0049] The term 'computer' is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realize that such processing capabilities are incorporated into many different devices and therefore the term 'computer' includes PCs, servers, mobile telephones, personal digital assistants and many other devices.
[0050] Those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program.
Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.
[0051] Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person.
[0052] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages.
[0053] Any reference to 'an' item refers to one or more of those items. The term 'comprising' is used herein to mean including the method blocks or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or apparatus may contain additional blocks or elements.
[0054] The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, individual blocks may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.
[0055] It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art. Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of this invention.
Claims (19)
- Claims 1. A method of brokering a trusted connection between two virtual assets in a connection brokerage system comprising a plurality of service-requesting virtual assets and service-producing virtual assets, the method comprising: receiving, by a registration component of a registration system of the connection brokerage system, a service request from a service requesting virtual asset; determining, based on service descriptors associated with virtual assets held in one or more registration components of the registration system, a service providing virtual asset capable of providing the requested service; and negotiating a connection between the service requesting virtual asset and the determined service providing virtual asset using a first verification service and a second verification service, wherein the first verification service dynamically verifies if at least one identity-based credential of a controlling entity associated with an external asset represented within the connection brokerage system by the service requesting virtual asset which is received from a component of the registrar computer system matches a corresponding identity-based credential, wherein the second verification service dynamically verifies if at least one credential associated with an external asset represented within the connection brokerage system by the service providing virtual asset which is received from a component of the registrar computer system matches a corresponding credential, wherein, if both verifications are successful and if a connection is successfully negotiated between the two virtual assets by the registrar computer system of the connection brokerage service, the two virtual assets establish the connection as a trusted connection.
- 2. The method according to claim 1, wherein the at least one credential associated with an external asset represented within the connection brokerage system by the service providing virtual asset comprises an identity-based credential of a controlling entity associated with the external asset.
- 3. The method according to claim 1 or 2, wherein the at least one credential associated with an external asset represented within the connection brokerage system by the service providing virtual asset comprises an attribute-based credential of the external asset.
- 4. The method according to any of the preceding claims, wherein the first and second verification services are third party verification services controlled by a different entity to the entity controlling the connection brokerage system.
- 5. The method according to any of the preceding claims, wherein the first and second verification services authenticate the credentials in real time as the connection is being negotiated by the connection brokerage system.
- 6. The method according to any preceding claim, wherein the credentials comprise decentralised identifiers associated with one or more self-identifying credentials.
- 7. The method according to any preceding claim, wherein the external asset of the service providing virtual asset comprises a real or simulated device generating data used by the service offered by the virtual asset.
- 8. A method according to claim 7, wherein the controlling entity associated with the external asset is registered as the owner of the real or simulated device within the connection brokerage system.
- 9. A method according to claim 8, wherein the at least one identity-based credential comprises one or more of: a name of the registered owner; an address for the registered owner; an account identifier for the registered owner.
- 10. The method according to any preceding claim, wherein the first verification service is indicated in a registry entry for the service requesting virtual asset in the registration system of the connection brokerage system and the second verification service is indicated in a registry entry for the service providing virtual asset in the registration system of the connection brokerage system.
- 11. The method according to any preceding claim, wherein the service providing virtual asset determines if the service request can be fulfilled using an access control list which implements an access policy for the external asset before accepting the service request from the service requesting virtual asset.
- 12. The method according to any preceding claim, wherein the verification service indicates a level of confidence to the registrar computer system in the identity of the entity associated with either or both of the service requesting and service providing virtual assets, and the connection is only successfully negotiated if the level of confidence exceeds a threshold level of confidence established by either virtual asset in the registry system.
- 13. The method of claim 12, wherein the threshold level of confidence is dependent on the requested service.
- 14. The method according to any preceding claim, wherein the service providing virtual asset executes a command received from the service requesting virtual asset in response to successful verification of the at least one identity-based credential of a controlling entity associated with the external asset represented within the connection brokerage system by the service requesting virtual asset.
- 15. The method according to any preceding claim, wherein the service requesting virtual asset identifies data received from the service providing virtual asset as trusted data in response to successful verification of the at least one credential associated with the external asset represented within the connection brokerage system by the service providing virtual asset.
- 16. A system configured to perform the method of any of the preceding claims.
- 17. The system according to claim 16, wherein the system comprises connection brokerage system and the connection brokerage system comprises a plurality of service-requesting virtual assets and service-producing virtual assets.
- 18. Computer program code adapted to cause a computer to perform the method of any of the preceding claims when the program is run on the computer.
- 19. Computer readable medium arranged to store the computer program code according to claim 18.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB2208046.9A GB2619315B (en) | 2022-05-31 | 2022-05-31 | Mutual trust environment |
PCT/EP2023/064268 WO2023232712A1 (en) | 2022-05-31 | 2023-05-26 | Mutual trust environment |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB2208046.9A GB2619315B (en) | 2022-05-31 | 2022-05-31 | Mutual trust environment |
Publications (3)
Publication Number | Publication Date |
---|---|
GB202208046D0 GB202208046D0 (en) | 2022-07-13 |
GB2619315A true GB2619315A (en) | 2023-12-06 |
GB2619315B GB2619315B (en) | 2024-06-26 |
Family
ID=82324296
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
GB2208046.9A Active GB2619315B (en) | 2022-05-31 | 2022-05-31 | Mutual trust environment |
Country Status (2)
Country | Link |
---|---|
GB (1) | GB2619315B (en) |
WO (1) | WO2023232712A1 (en) |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180375651A1 (en) * | 2017-06-27 | 2018-12-27 | Uniken, Inc. | Method for leveraging a secure telecommunication session |
EP3056032B1 (en) * | 2013-10-08 | 2019-12-04 | Iotic Labs Limited | Method and apparatuses for brokering communications for internet of things (iot) |
-
2022
- 2022-05-31 GB GB2208046.9A patent/GB2619315B/en active Active
-
2023
- 2023-05-26 WO PCT/EP2023/064268 patent/WO2023232712A1/en unknown
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3056032B1 (en) * | 2013-10-08 | 2019-12-04 | Iotic Labs Limited | Method and apparatuses for brokering communications for internet of things (iot) |
US20180375651A1 (en) * | 2017-06-27 | 2018-12-27 | Uniken, Inc. | Method for leveraging a secure telecommunication session |
Also Published As
Publication number | Publication date |
---|---|
GB202208046D0 (en) | 2022-07-13 |
GB2619315B (en) | 2024-06-26 |
WO2023232712A1 (en) | 2023-12-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11586709B2 (en) | Secure provisioning and management of devices | |
US10516736B2 (en) | Internet of things | |
US10079832B1 (en) | Controlling user creation of data resources on a data processing platform | |
EP3467650A1 (en) | Controlling user creation of data resources on a data processing platform | |
JP2023120287A (en) | Scalable certificate management system architecture | |
GB2619315A (en) | Mutual trust environment | |
Dogan et al. | Distributed ledger-based authentication and authorization for Industrie 4.0 components |