US20190372981A1 - Methods and resources for creating permissions - Google Patents
Methods and resources for creating permissions Download PDFInfo
- Publication number
- US20190372981A1 US20190372981A1 US16/448,718 US201916448718A US2019372981A1 US 20190372981 A1 US20190372981 A1 US 20190372981A1 US 201916448718 A US201916448718 A US 201916448718A US 2019372981 A1 US2019372981 A1 US 2019372981A1
- Authority
- US
- United States
- Prior art keywords
- permissions
- subject
- owner
- data processing
- management resource
- 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.)
- Abandoned
Links
Images
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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/101—Access control lists [ACL]
-
- 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
-
- 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
-
- 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- 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/104—Grouping of entities
Definitions
- the technical field relates to data processing devices and in particular to creating permissions and managing permissions for data processing devices.
- subject devices may be connected to each other and to central resources as part of the “Internet of Things” (IoT).
- IoT Internet of Things
- a temperature hub in a home environment may gather information from various subject devices, such as temperature sensors around the home, and control the activation of heaters/air conditioning units based on the gathered information.
- the subject devices may generate information thereon, e.g. information relating to energy usage, efficiency, which may be sent to a cloud service and accessed by an interested party e.g. via a web application.
- a subject device such as an entry sensor in a smart-door, may gather authorization information from a data processing device in communication therewith and control the activation of an associated door lock based on the authorization information.
- the subject device may generate information thereon e.g. information relating to entry attempts, which may be sent to a cloud service to be accessed by a party.
- the present techniques seek to address these problems.
- FIG. 1 schematically shows an example of a data processing device for use with the present techniques
- FIG. 2 schematically shows an example of a subject device which can communicate with the data processing device of FIG. 1 ;
- FIG. 3 schematically shows the data processing device of FIG. 1 in a network
- FIG. 4 schematically shows the data processing device of FIG. 1 communicating with a subject device to take ownership thereof;
- FIG. 5 schematically shows the data processing device of FIG. 1 communicating with a subject device to access features of the subject device;
- FIG. 6 schematically shows a guest data processing device in a network communicating with a subject device
- FIG. 7 a schematically shows an owner granting permission to the guest data processing device of FIG. 6 to access a subject device using a permissions management infrastructure
- FIG. 7 b schematically shows an owner, using the data processing device of FIG. 1 , granting permission to the guest data processing device of FIG. 6 to access a subject device;
- FIG. 8 schematically shows the guest data processing device of FIG. 6 communicating with a subject device
- FIG. 9 schematically shows a permissions management resource
- FIG. 10 a schematically shows the guest data processing device of FIG. 6 in a network communicating with a plurality of subject devices
- FIG. 10 b schematically shows the guest data processing device in a network communicating with a plurality of subject devices
- FIG. 11 a schematically shows a plurality of data processing devices in a network communicating with a permission management infrastructure
- FIG. 11 b schematically shows the plurality of data processing devices in a network communicating with the permission management infrastructure of FIG. 11 a.
- FIG. 1 schematically shows an example of a data processing device 1 for use with the present techniques.
- the data processing device 1 may comprise credentials relating to an authorized party associated with the data processing device 1 (e.g. an owner), which may be used to verify the identity of the owner to other resources remote therefrom e.g. data processing devices, applications running on remote devices, cloud platforms, directories etc.
- the data processing device 1 which may comprise credentials, hereinafter “envoy device” may also be capable of running applications to process data received from any such remote resources in order to access, interact with and/or verify the identity and/or to take ownership thereof on behalf of the owner.
- Envoy device may also be capable of running applications to process data received from any such remote resources in order to access, interact with and/or verify the identity and/or to take ownership thereof on behalf of the owner.
- the envoy device 1 may be capable of defining permissions associated with data processing devices which the owner has taken ownership of, and communicating such permissions to any such data processing device.
- the envoy device 1 may comprise a processing element 3 coupled to a storage element 4 , comprising, for example memory circuitry (volatile memory (V) & non-volatile memory (NV), such as such as flash and ROM).
- the memory circuitry 4 may store programs executed by the processing element 3 .
- a non-volatile memory region may be both read from and written to, but for which read and/or write protection may be applied so that a protected region (not shown) of NV can only be accessed by privileged software executed by the processing element 3 .
- the protected region may store confidential information such as device identifiers, cryptographic keys, certificates, e.g. comprising permissions such as an access control list (ACL) therein.
- the protected region may also comprise a device identifier, such as a unique device identifier which uniquely identifies the envoy device 1 .
- the unique device identifier may take any suitable form, and may for example be a semantic identifier defined by an owner, an IPv6 address, IPv4 address, serial number, Universally Unique Identifier (UUID) or Globally Unique Identifier (GUID) etc.
- the envoy device 1 also comprises communication circuitry 6 for communicating with remote data processing devices/resources (not shown in FIG. 1 ).
- the communication circuitry 6 may use a wireless communication 7 , such as, for example, wireless local area network (WiFi), short range communication such as radio frequency communication (RFID), near field communication (NFC) or communications used in wireless sensor networks such as ZigBee, Bluetooth and/or Bluetooth Low energy (BLE).
- WiFi wireless local area network
- RFID radio frequency communication
- NFC near field communication
- BLE Bluetooth Low energy
- the communication circuitry 6 may use a cellular network such as 3G or 4G.
- the communication circuitry 6 may also, in some examples, use wired communication such as a fibre optic or metal cable (not shown).
- the communication circuitry 6 could also use two or more different forms of communication, such as several of the examples given above in combination.
- the envoy device 1 may also comprise input/output (I/O) circuitry 8 such as a user interface (UI) (e.g. buttons) to allow the owner to interact with the envoy device 1 .
- I/O input/output
- the envoy device 1 may comprise a display 9 e.g. an organic light emitting diode (OLED) display, for communicating messages to the owner.
- the display may also be a touch screen to receive inputs from the owner.
- the envoy device 1 may comprise large scale data processing devices such as a tablet computer, often the envoy device 1 comprises a relatively small scale data processing device such as a smartphone or a wearable data processing device, for example a smart-watch.
- the envoy device 1 may comprise other hardware/software components not described herein depending on the specific function of the envoy device 1 .
- the envoy device 1 may comprise a global positioning system (GPS) to capture and record movement, and to generate operational data accordingly.
- GPS global positioning system
- FIG. 2 schematically shows an example of a subject device 20 which can communicate with an envoy device using the present techniques.
- the subject device 20 may be any device which gathers data for transmitting to a remote resource (e.g. the envoy device 1 , web application), which may verify credentials received from a remote resource and/or which may be accessed by a remote resource.
- a remote resource e.g. the envoy device 1 , web application
- the subject device 20 may be a connected device in the Internet of Things (IoT) such as a wireless sensor or actuator.
- IoT Internet of Things
- the subject device 20 comprises a processing element 21 , and storage element 24 , comprising, for example memory circuitry 24 (e.g. volatile memory (V) and/or non-volatile memory (NV), such as such as flash and ROM).
- memory circuitry 24 e.g. volatile memory (V) and/or non-volatile memory (NV), such as such as flash and ROM).
- the memory circuitry 24 may store programs executed by the processing element 21 .
- the memory circuitry 24 comprises a NV memory region which can be both read from and written to, but for which read and/or write protection may be applied so that the protected region (not shown) of NV can only be accessed by privileged software executed by the processing element 21 .
- the protected region may store confidential information, for example cryptographic keys, ACLs or certificates received from a resource remote therefrom, such as an envoy device 1 , or a cloud service.
- the protected region also comprises a device identifier, such as a unique device identifier which uniquely identifies the subject device 20 .
- a device identifier such as a unique device identifier which uniquely identifies the subject device 20 .
- the unique device identifier may take any suitable form, for example as described above.
- the memory circuitry 24 may also comprise further device identifiers which correspond to attributes associated with the subject device 20 .
- device type identifiers may provide further information about the subject device 20 , whereby the device type identifiers may include, for example, a device manufacturer identifier (e.g. ‘Made_by_CompanyY’), an owner identifier (e.g. ‘Owner_is_Alice’), a device class identifier (e.g. ‘temperature_sensor’), and/or a device location identifier (e.g. ‘living_room’).
- a device manufacturer identifier e.g. ‘Made_by_CompanyY’
- an owner identifier e.g. ‘Owner_is_Alice’
- a device class identifier e.g. ‘temperature_sensor’
- a device location identifier e.g. ‘living_room’
- device capability identifiers may provide information relating to the specific functionality of the subject device such as, for example a text description of the device functionalities e.g. ‘Subject device can measure temperature’, ‘Subject device can authorise received credentials and unlock connected doors,’ ‘Subject device can publish data on the Internet via web applicationXYZ’.
- the device identifiers may also comprise data type identifiers relating to the type of data generated by the device. For example, in the case of a temperature sensor, the data type may be classified as ‘low_sensitive_data,’ while in the case of an entry sensor, the data type may be classified, for example as ‘high_sensitive_data’ or ‘secret_data’.
- the device identifiers may be hierarchical in form, whereby, a device identifier may have different levels associated therewith.
- the location identifier may comprise multiple levels ‘house/downstairs/kitchen.’
- a device belonging to a company may comprise the device location identifier ‘CompanyY_HeadQuarters/Building6/2ndFloor/Office8’
- a device class identifier may take the hierarchical form, to provide multiple levels of device class identifier.
- a temperature sensor in a house may comprise the device class identifier: ‘household_appliance/sensor/temperature_sensor’, while an entry sensor may, for example, comprise the device class identifier ‘security_appliance/sensor/entry_sensor’.
- device identifiers may be permanently written to memory on a subject device e.g. at manufacture, such as the device class identifier (e.g. sensor/temperature_sensor) device manufacturer identifier (Made by ACMESensor's Ltd′), and/or the unique device identifier (e.g. an IPv6 address), an authorized party e.g. an owner, may set other device identifiers, or add hierarchical levels to the device identifiers.
- the device class identifier e.g. sensor/temperature_sensor
- the unique device identifier e.g. an IPv6 address
- an authorized party e.g. an owner, may set other device identifiers, or add hierarchical levels to the device identifiers.
- the owner may set whether the subject device should be designated a ‘security_appliance’ or a ‘household_appliance’, who the owner is, and/or the owner may classify the type of data generated by the device e.g. ‘high_sensitive_data’ or ‘low_sensitive_data’.
- the owner may, for example, set the device identifiers via an application running on an envoy device in communication with the subject device.
- the device identifiers may also provide contextual information relating to how the owner intends to use the device.
- the subject device 20 may also comprise communications circuitry 26 for communicating with remote data processing devices and/or resources, such as envoy devices, or cloud services, to receive requests/commands/credentials/permissions (e.g. in an ACL) therefrom or to push data thereto.
- communications circuitry 26 may include wireless communications 27 e.g. BLE, Bluetooth, ZigBee, WiFi, and/or cellular 3G/4G.
- the subject device 20 may further comprise I/O circuitry 28 , such as sensing circuitry to sense inputs from the surrounding environment to generate operational data and/or to provide an output to control an operation of the subject device 20 e.g. to control a transistor to determine the operation of a buzzer, a light emitting diode(s) or a relay (not shown).
- I/O circuitry 28 such as sensing circuitry to sense inputs from the surrounding environment to generate operational data and/or to provide an output to control an operation of the subject device 20 e.g. to control a transistor to determine the operation of a buzzer, a light emitting diode(s) or a relay (not shown).
- the subject device 20 may be a smart-lightbulb comprising an array of LEDs, whereby an owner may control the emission the LEDs via an application running on a remote device.
- the subject device 20 may be an embedded device such as a healthcare monitor, which generates operational data related to its owner's health such as heart rate, blood sugar level and/or temperature and sends the operational data to a remote server for processing of the operational data, which may then be accessed by the owner, or a select group of users authorized to access the operational data by the owner.
- a healthcare monitor which generates operational data related to its owner's health such as heart rate, blood sugar level and/or temperature and sends the operational data to a remote server for processing of the operational data, which may then be accessed by the owner, or a select group of users authorized to access the operational data by the owner.
- the subject device 20 may be an embedded temperature sensor, which generates operational data based on the temperature of the surrounding environment, and publishes the operational data on a web application on behalf of its owner.
- the subject device 20 may be a smart fridge, which detects, for example, the date of expiry on foodstuff therein and alerts the owner via an application running on the owner's smart-phone if any food is approaching expiry.
- the subject device 20 may be an entry sensor on a smart door, which is operable to lock/unlock the door based on communications received from a data processing device.
- the subject device 20 may be a wearable device, for example a fitness band which generates data relating to movement, for example capturing distance walked/run/swam, or elevation ascended/descended.
- a wearable device for example a fitness band which generates data relating to movement, for example capturing distance walked/run/swam, or elevation ascended/descended.
- the subject device 20 may be a smart-pen, configured to generate operational data relating to the specific movement of the pen, for example alphanumeric characters or pictures.
- the subject device 20 may also be configured to create files such as JPEG/Vector (e.g. SVG)/Portable Document Format (PDF) recording the specific movements, and to send the data to a remote server for processing of the operational data.
- JPEG/Vector e.g. SVG
- PDF Portable Document Format
- subject devices listed above are by way of example only. It will further be appreciated that subject devices may comprise other hardware/software components not described herein depending on the specific function of the subject device.
- an envoy device as described above may be capable of providing similar functionalities as a subject device, in that an envoy device may sense inputs, process data, and communicate with resources remote therefrom, it will be appreciated that envoy devices will generally have increased processing capabilities in comparison to subject devices, and be capable of providing increased functionalities and greater interaction with a user in comparison to subject devices.
- the envoy device may comprise a mobile phone or a smart watch, with which a user can interact, e.g. via a plurality of applications running thereon.
- FIG. 3 schematically illustrates an example of a system 99 comprising envoy device 1 communicating with a plurality of subject devices 20 a - 20 g in a local network 100 (e.g. within a home network or office environment); whereby the envoy device 1 is in communication with a permissions management resource 102 remote therefrom, whereby the permissions management resource 102 is configured to manage the generation and distribution of commands, credentials and/or permissions for data processing devices (e.g. the envoy devices/subject devices).
- a local network 100 e.g. within a home network or office environment
- the permissions management resource 102 is configured to manage the generation and distribution of commands, credentials and/or permissions for data processing devices (e.g. the envoy devices/subject devices).
- the permissions management resource 102 is described as a cloud platform on an external network 104 (e.g. the internet), in communication with envoy devices/subject devices located in a local network 100 (e.g. a mesh network).
- a local network 100 e.g. a mesh network
- the permissions management resource 102 is not limited to being a cloud platform, and may be provided as a data processing device within the local network 100 , or an application running thereon.
- the envoy device 1 is taken to belong to an owner of the subject devices 20 a - 20 g , i.e. a party who is authorized, for example, to have unrestricted access to the subject devices e.g. to configure/set permissions/control the subject device.
- the envoy device 1 may communicate with the subject devices 20 a - 20 g using any suitable communications protocol (e.g. Bluetooth/BLE/ZigBee), while the envoy device 1 may communicate with the permissions management infrastructure 102 using any suitable communications protocol (e.g. BLE, ZigBee, WiFi, cellular 3G/4G).
- any suitable communications protocol e.g. Bluetooth/BLE/ZigBee
- any suitable communications protocol e.g. BLE, ZigBee, WiFi, cellular 3G/4G.
- the envoy device 1 may also communicate with the permissions management resource 102 using intermediate devices such as routers (e.g. border routers/Internet Service Provider (ISP) routers).
- routers e.g. border routers/Internet Service Provider (ISP) routers.
- the subject devices may also communicate with each other, to control the functionality thereof (e.g. via BLE, Zigbee, wired etc.), whist the subject devices may also communicate with the permissions management infrastructure 102 directly (e.g. via WiFi, cellular 3G/4G) using intermediate devices as required, or indirectly e.g. via envoy device 1 or a further data processing device.
- the permissions management infrastructure 102 directly (e.g. via WiFi, cellular 3G/4G) using intermediate devices as required, or indirectly e.g. via envoy device 1 or a further data processing device.
- the permissions management resource is depicted as a permissions management infrastructure 102 on the cloud comprising a data processing engine 106 (e.g. software running on a server located on the cloud), hereinafter referred to as a permission creation engine (PCE) 106 , which is configured to generate permissions for resources such as data processing devices (e.g. envoy devices, subject devices), applications and/or system processes, whereby the generated permissions may be defined by an owner of the resource at the permissions management infrastructure 102 e.g. via an application running on the owner's envoy device 1 or on another data processing device in communication with the permissions management infrastructure 102 . The permissions defined by the owner may then be generated at the permissions management infrastructure 102 using PCE 106 .
- a data processing engine 106 e.g. software running on a server located on the cloud
- PCE permission creation engine
- the owner may define what functions a particular subject device is permitted to undertake, or where a subject device should publish information on behalf of its owner. Additionally or alternatively, the owner may define the amount of access a guest device is permitted to have with respect to the features and/or functionality of one or more subject devices, and the owner may also define the limits of any such access and/or the duration thereof.
- permissions may be automatically generated by the PCE 106 based on an analysis of input data comprising rules/policies (predefined or customized by an authorized party), contextual data and/or guest identity. Such functionality is described in greater detail with relation to FIGS. 9 and 10 ).
- the permissions management infrastructure 102 may also comprise identity management engine (IDM) 108 (e.g. software running on a server located on the cloud), which is configured to manage the permissions generated at the PCE 106 , e.g. by distributing the permissions to one or more data processing devices (e.g. a subject device and/or envoy devices) so the permissions can be implemented on the data processing devices.
- IDM identity management engine
- the generated permissions comprise an access control list (ACL), whereby an ACL may define the functionality which the subject device is authorized to undertake.
- ACL access control list
- a subject device may be configured to control other subject devices e.g. an entry sensor may be permitted to unlock a door or to activate an alarm, while a temperature sensor may be permitted to adjust the output of an air-conditioning unit.
- an ACL may specify the location of a web page or a server to which any operational data generated by a subject device should be pushed.
- an ACL may specify whether any data processing devices are authorized to access features/functionality of a subject device.
- a subject device may be provided with an ACL which contains the instructions:
- a subject device having such an ACL may permit ‘Guest Device X’ to read and write from/to the file A on the subject device, while the ACL may permit ‘Guest Device Y’ to only read from file B on the subject device.
- the ACL may comprise a list of specific permissions relating to activities which the owner permits a guest device to undertake, e.g.
- an ACL may have an expiration period, after which the ACL is no longer valid.
- an ACL on a subject device may be valid for a period of 24 hours, whereby a guest device may be permitted to access the subject device during the period the ACL is valid, but whereby the guest device will not be able to access the subject device after that period, and will have to request an updated ACL.
- a subject device may utilise a blacklist of permissions, which, for example, may comprise an ACL comprising details of functions prohibited to be performed by the subject device (e.g. do not generate data after 1900 hrs).
- the blacklist of permissions may comprise details (e.g. device identifiers, public keys, network addresses) of data processing devices/applications/resources prohibited from accessing the subject device.
- the owner may, via envoy device or another data processing device, define the details and/or functions to be included within the blacklist, and may further define which subject devices should implement the blacklist.
- the PCE 106 may then generate the blacklist, while the IDM 108 may communicate the blacklist to the subject devices directly or indirectly.
- Such functionality allows the owner to prevent unauthorized access to subject devices, for example by rogue 3 rd parties.
- subject devices 20 a - g are owned by the same owner, which also owns envoy device 1 , whereby:
- Subject device 20 a is depicted as a temperature sensor configured to detect the temperature of the surrounding environment and to generate operational data based on the sensed temperature.
- Subject device 20 b is depicted as a light sensor 20 b configured to detect levels of light in the surrounding environment, and to generate operational data based on the sensed levels.
- Subject device 20 c is depicted as an entry sensor 20 c , configured to communicate with other data processing devices and to determine the authorization of such devices.
- Subject device 20 d is depicted as an air conditioning unit 20 d , having functionality (e.g. heat/cool output), which may be controlled by a data processing device in communication therewith.
- functionality e.g. heat/cool output
- Subject device 20 e is depicted as a smart lightbulb, having functionality (e.g. on/off, dimming), which may be controlled by a data processing device in communication therewith.
- functionality e.g. on/off, dimming
- Subject device 20 f is depicted as a smart door lock, having functionality (e.g. lock/unlock), which may be controlled by a data processing device in communication therewith.
- functionality e.g. lock/unlock
- Subject device 20 g is depicted as a smart alarm having functionality (e.g. sound buzzer) which may be controlled by a data processing device in communication therewith.
- functionality e.g. sound buzzer
- the temperature sensor 20 a , air conditioning unit 20 d , light sensor 20 b and lightbulb 20 e and alarm 20 g are considered to be part of a secure zone within network 100 (e.g. within the interior of an owner's home), while the entry sensor 20 c and door lock 20 f are considered to be part of a non-secure zone within the local network 100 (e.g. at the exterior of the owner's home), with the boundary between secure and non-secure zones depicted as 110 .
- the boundary 110 may not necessarily be a physical boundary.
- the owner may, via an application running on the envoy device 1 , set permissions at the PCE 106 for each of the subject devices 20 a - g .
- the PCE 106 may generate an ACL corresponding to the permissions set by the owner, whereby any ACL is transmitted to the subject devices by IDM 108 directly (e.g. via WiFi) or indirectly e.g. via envoy device 1 , whereby the ACL will be implemented thereon.
- the owner may set permissions at the PCE 106 to instruct the temperature sensor 20 a to push all operational data generated thereon to a specific web service on the internet.
- the permissions may relate to communicating with another data processing device, whereby, for example, the owner instructs the temperature sensor 20 a to send operational data to the air conditioning unit 20 d.
- the owner may also set permissions for the air conditioning unit 20 d at the PCE, whereby, for example, the owner instructs the air conditioning unit 20 d to accept operational data from the temperature sensor 20 a , and perform an action accordingly, such as “maintain temperature at 19° C.”, “power off between 0101 and 0830.”
- the temperature sensor 20 a will generate operational data and send the operational data to the air conditioning unit 20 d .
- the air conditioning unit 20 d is permitted to receive data from the temperature sensor 20 a , the operational data will be processed and the output of the air conditioning unit 20 d adjusted according to the instructions in the ACL.
- the owner may set permissions at the PCE 106 to allow the light sensor 20 b to push all operational data generated thereon to a web service on the cloud for access by any interested party.
- the PCE 106 will generate an ACL corresponding to the permissions set by the owner, whereby the ACL is transmitted to the light sensor 20 b by IDM 108 , e.g. via envoy device 1 .
- the owner may set permissions at the PCE 106 to allow the entry sensor 20 c to authorise access to certain guests (e.g. as described below) and on authorizing the guests to push all operational data generated thereon (e.g. capturing the date and time and guest identification) to a web service on the cloud for access by the owner.
- the permissions may relate to communicating with another data processing device(s), whereby, for example, the owner instructs the entry sensor 20 c to send command instructions to the air conditioning unit 20 d , light bulb 20 e , door lock 20 f and or smart alarm 20 g based on the operational data.
- the owner may also set permissions for the air conditioning unit 20 d , lightbulb 20 e , door lock 20 f and/or smart alarm 20 g at the PCE based on instructions received from the entry sensor 20 c , whereby, for example, the owner instructs the air conditioning unit 20 d , lightbulb 20 e and door lock 20 f to perform respective actions, such as for example:
- the entry sensor 20 a will authorise a guest to enter the house and, on doing so, may instruct the door lock 20 f to unlock, the air conditioning unit 20 d to turn on and maintain 19° C., and/or instruct the light bulb 20 e to turn on.
- the entry sensor may instruct the smart alarm 20 g to activate the buzzer, and instruct the lightbulb 20 e to turn on.
- the owner may, using the permissions management infrastructure 102 , define the permissions for a particular subject device and manage the implementation of the permissions on the subject devices.
- the PCE 106 may generate an ACL specifying the permissions set by the owner, whereby the IDM 108 may manage the distribution of the ACLs to the respective subject devices, whereby the subject devices are configured to perform the operations specified in the ACLs.
- the permissions may be transmitted directly to the subject devices from the permissions management infrastructure 102 . Therefore, using such functionality, the subject devices may be required to have a constant network connection to receive the ACLs.
- the permissions may be transmitted to the subject devices indirectly e.g. via the owners envoy device 1 or a data processing device.
- the envoy device 1 may receive the ACL from the IDM 108 and transmit the ACL to the to the subject device when in proximity thereto, e.g. using BLE.
- the subject device is not required to have a constant network connection, and can receive any permissions locally over a suitable communications protocol.
- the subject devices may verify that the permissions are transmitted thereto by an authorized device and/or resources using any suitable verification protocol.
- cryptographic keys e.g. symmetric/asymmetric keys
- Such keys may be 128-bit or 256-bit AES (Advanced Encryption Standard) keys or elliptic curve cryptography (ECC) keys.
- the subject devices 20 a - 20 g may comprise a public key of the owner Puk (Owner) and/or the public key of the permissions management infrastructure Puk (PMI) stored in memory thereon.
- Puk owner
- PMI permissions management infrastructure
- the public keys may be provided to the subject devices during a registration process between the owner and the respective subject devices, e.g. using the owner's envoy device 1 , whereby the subject devices may recognise any public keys provided thereto during the registration process as being associated with its owner, or a party authorized by its owner to interact therewith. Furthermore, a subject devices may also send the owner its public key e.g. during the registration process.
- the owner and/or permissions management infrastructure 102 may sign the ACL with their respective private keys before sending the ACL to the subject device, and, before implementing the ACL, the subject device may verify that the ACL is from an authorized party by verifying the signature using the corresponding public key(s).
- the owner may send a description of any subject devices which it has taken ownership of to the permissions management infrastructure 102 , such that the permissions management 102 is aware of the subject devices.
- the description of ownership may comprise the device identifiers of the respective subject devices and or the respective public keys thereof.
- communications from the envoy device 1 /permissions management infrastructure 102 may be encrypted using the public key Puk (Subject) of the subject device to which permissions are to be sent, whereby the subject device can decrypt the communications using the corresponding private key Prk (Subject) .
- the owner may also add new subject devices to the network and take ownership thereof.
- new subject device 22 which is depicted as a 2 nd temperature sensor
- the new subject device 22 may broadcast its attributes (e.g. device identifiers) and broadcast it's availability for an owner to take ownership thereof (as shown at Step 200 FIG. 4 ).
- the owner may, via an application running on the envoy device 1 , take ownership of the new subject device 22 , whereby for example, a credential associated with the owner and/or an authorized party is communicated to the subject device 22 and stored in memory circuitry provided thereon, whereby the credential is taken to be that of the owner.
- the credential is a public key (Puk (Owner) ) of an asymmetric key pair of the owner, whereby Puk (Owner) is received by the new subject device 22 and stored in a protected region of memory thereat, and taken to be the public key of its owner (Step 202 ).
- the new subject device 22 may transmit a communication to the envoy device 1 to confirm receipt of the credential and that the owner has taken ownership thereof (Step 204 ).
- a communication may comprise the device identifiers of the subject device 22 .
- the owner may send a description of ownership to the permissions management infrastructure 102 , such that the permissions management 102 is aware of the subject device 22 .
- the corresponding cryptographic key e.g. a private key (Prk (Owner) ), of the owner may be stored within the protected region at the envoy device 1 .
- the private key (Prk (Owner) ) may be communicated to the permissions management infrastructure 102 and stored thereat e.g. at a protected region 109 of the IDM 108 .
- the private key Prk (Owner) may be provided to the permissions management infrastructure 102 during a registration process between the owner and permissions management infrastructure 102 .
- the new subject device 22 may comprise device identifiers provisioned thereon at manufacture and/or which are set by the owner on taking ownership of the new subject device 22 e.g. via an application.
- FIG. 5 shows an example of an owner interacting with the new subject device 22 using envoy device 1 . Having taken ownership of the new subject device 22 , the owner may be able to access the new subject device 22 using the envoy device 1 .
- the owner may, via envoy device 1 , request to access the new subject device 22 .
- the new subject device 22 may generate and transmit a communication comprising a cryptographic nonce to the envoy device 1 , whereby the envoy device 1 signs the nonce with the owner's private key (Prk (Owner) ).
- the signed nonce is transmitted to the new subject device 22 , which verifies the signature using the owner's public key (Puk (Owner) ) stored thereon, whereby, on verification of the signature, the envoy device 1 is granted access to the new subject device 1 (Step 216 ).
- the owner's public key Puk (Owner)
- FIG. 6 shows an example of a guest envoy device 2 , hereinafter “guest device” 2 added to the network 100 within the system 99 , whereby a guest requests, via the guest device 2 , permission to access one or more subject devices ( 20 a - 20 g or 22 ) within the network 100 .
- FIG. 7 a schematically shows an example of an owner granting permission to the guest to access subject device 22 using permissions management infrastructure
- FIG. 7 b schematically shows an example of an owner granting permission to the guest to access subject device 22 using envoy device 1
- FIG. 8 schematically shows an example interaction between the guest device 2 and subject device 22 .
- the guest device 2 may be any suitable data processing device e.g. a smartwatch, smartphone, tablet etc.
- the guest requests permission to access subject device 22 .
- the guest device 2 may request permission from the permissions management infrastructure 102 directly e.g. via an application running on the guest device 2 (as depicted by feature 131 FIG. 6 ).
- the guest device 2 may request permission from the permissions management infrastructure 102 indirectly via a suitable data processing device such as an owner's envoy device 1 (as depicted by features 132 , 133 FIG. 6 ) or a subject device.
- a suitable data processing device such as an owner's envoy device 1 (as depicted by features 132 , 133 FIG. 6 ) or a subject device.
- permissions management infrastructure 102 may request a public key Puk (Guest) from the guest device 2 .
- the guest device 2 may automatically provide the public key Puk (Guest) as part of the request.
- the guest device 2 may also provide other device identifiers to the permissions management infrastructure, either automatically or on request e.g. unique device identifier (e.g. IPv6 address) and/or device owner identifiers (‘Owned by GuestX’).
- the permissions management infrastructure 102 may comprise a database 111 , comprising device identifiers associated with data processing devices (e.g. guest devices) which are permitted/prohibited from accessing subject devices. Therefore, the permissions management infrastructure 102 may check the database 111 as to whether the guest device 2 making the request is permitted to access the subject device for which permission is requested.
- data processing devices e.g. guest devices
- the permissions management infrastructure 102 may communicate with the owner e.g. via envoy device 1 to verify if the guest device 2 should be permitted to access the subject device 22 .
- the permissions management infrastructure 102 may communicate with the owner via a user interface (UI) on the envoy device 1 and provide an option to the owner to confirm whether or not permission should be granted to the guest device 2 .
- UI user interface
- a proposal communication may be communicated to the envoy device 1 from the IDM 108 and displayed to the owner via the UI, whereby the proposal communication may state:
- the owner may then respond by providing an input e.g. via a touch input, corresponding to ‘Yes’ or ‘No’, which is transmitted as a consent status communication to the permissions management infrastructure 102 e.g. to the IDM 108 .
- the owner may also set/limit the permissions for the guest device 2 in the consent status communication e.g. via an application running on the envoy device 1 .
- the PCE 106 may generate the respective permissions (Step 222 ), which in the present example comprises an ACL as previously described.
- the PCE 106 then communicates the ACL to the IDM 108 .
- the IDM 108 combines the guest device's public key Puk (Guest) with the ACL to provide certificate 120 and signs the certificate 120 with a private key Prk (Owner) associated with the owner.
- Prk private key
- the signed certificate 120 is then transmitted to the guest device 2 (Step 224 ), either directly (as indicated by feature 131 ( FIG. 6 )) or indirectly e.g. via envoy device 1 (as indicated by features 132 and 133 ( FIG. 6 )).
- the permissions management infrastructure 102 may be provisioned with the private key (Prk (Owner) ), e.g. upon registration of the owner with the permissions management infrastructure 102 e.g. using envoy device 1 .
- the permissions management infrastructure is not provisioned with the private key Prk (Owner) , but, as above, the subject device 22 may be provided with a public key Puk (PMI) of the permissions management infrastructure 102 , e.g. during the registration process by the owner. Therefore, the permissions management infrastructure 102 , may sign the certificate of 120 with the corresponding private key Prk (PMI) .
- PMI public key Puk
- the permission management infrastructure While in the example illustratively shown in FIG. 7 a the permission management infrastructure generates the permissions, in a further example, the owner may, e.g. using the envoy device 1 , generate the permissions and transmit the permissions directly to the guest device 2 , whereby the guest device 2 may then provide the permissions the subject devices. As such it will be seen that the permissions management infrastructure may comprise the envoy device 1 .
- Such functionality is illustratively shown in FIG. 7 b whereby the owner may, via an application running on the envoy device 1 define permissions for guest device 2 , whereby the application may automatically generate certificate 120 comprising ACL locally on the envoy device 1 and sign the certificate with the private key of the owner Prk (Owner) .
- the envoy device 1 may then transmit the signed certificate to the guest device 2 .
- the envoy device 1 may be provisioned with the public key Puk (Guest) of the guest device 2 .
- the envoy device 1 or guest device 2 uses the functionality illustratively shown in FIG. 7 b to have network connectivity with the permissions management infrastructure to generate permissions, as all permissions may be generated locally on the envoy device 1 and communicated to the guest device 2 using a suitable communications protocol e.g. BLE, Bluetooth and/or ZigBee.
- a suitable communications protocol e.g. BLE, Bluetooth and/or ZigBee.
- the envoy device 1 may also, when network connectivity is available, transmit a description of the permissions granted to the guest device 2 to the permissions management infrastructure 102 for storage thereat, so the permissions management infrastructure 102 is aware of the generated permissions and/or the guest device 2 .
- a description may comprise the signed certificate 120 .
- FIG. 8 shows an example of the guest device 2 , having the signed certificate 120 , requesting access to the subject device 22 and being authenticated by the subject device 22 .
- the subject device 22 is provided with the public key Puk (Guest) associated with the guest device 2 , which is stored in memory circuitry thereon. Provision of Puk (Guest) at the subject device 22 may occur at any suitable time and may be provided using a suitable communications protocol, by the guest device 2 , the envoy device 1 and/or directly or indirectly from the permissions management infrastructure 102 e.g. from IDM 108 .
- the guest device 2 requests access to the subject device 22 .
- the subject device 22 transmits a nonce to the guest device 2 in order for the guest device 2 to prove its identity.
- the guest device 2 signs the nonce with its private key Prk (Guest) which corresponds to public key Puk (Guest) provided to the subject device 22 (Step 230 ), and transmits the signed nonce and certificate 120 to the subject device 22 .
- Prk public key
- Puk Public key
- the signed nonce may be combined with certificate 120 (as shown in FIG. 8 ).
- the subject device 22 may verify the signed nonce e.g. using Puk (Guest) .
- the subject device 22 may then verify the signed certificate 120 using Puk (Owner) (or Puk (PMI) as appropriate), and, if verified, allow access thereof to the authenticated guest device 2 as specified in the ACL. (Step 238 .)
- the subject device 22 may be possible for the subject device 22 to further verify that the guest device sending the certificate is the guest device to which the certificate was actually issued by the IDM 108 , e.g. by comparing the public key of guest device in the certificate 102 with the public key provided to the subject device (at step 230 ).
- the guest device 2 when permissions are provided to the guest device 2 from permissions management infrastructure 102 on the cloud, the guest device 2 would be required to have a network connection to receive the certificate directly from the permissions management infrastructure 102 . However, once the certificate is received, the guest device 2 could provide the certificate to the subject device locally e.g. via BLE, whereby the subject device could authenticate the guest device and implement the ACL. Therefore, there is no requirement for the subject device to be constantly connected to a network.
- the guest device may receive the certificate indirectly from the permissions management infrastructure 102 , e.g. via an owner's envoy device using BLE.
- the guest device could then provide the certificate to the subject device locally e.g. via BLE, whereby the subject device could authenticate the guest device and implement the ACL. Therefore, there is no requirement for the guest device or the subject device to have a constant network connection.
- blacklists may be sent to the subject devices directly or indirectly.
- the blacklists may be communicated to the subject device via a guest device which itself is blacklisted. If, for example, the guest device requests access to a subject device, on receiving the request, the PCE may verify the device attributes of the requesting guest device. The PCE may then generate a certificate comprising a blacklist having the public key of the requesting guest device. The IDM may then encrypt the certificate using the public key of the subject device, sign the certificate using the private key of the permissions management infrastructure (or the owner as appropriate) and send the certificate to the guest device.
- the guest device On receiving the certificate, the guest device can present it to the subject device, which decrypts the certificate, verifies the signature and implements the blacklist, thereby denying access to subject device by the guest device.
- the guest device will not be aware of the blacklist within the certificate as the certificate will be encrypted.
- the permissions management infrastructure may push certificates comprising ACLs to the subject devices directly or indirectly e.g. via an owner envoy device or via guest device, whereby the subject devices may then authenticate the guest device and check the permissions in the ACL for each guest device locally.
- the subject devices receive the updated ACLs directly from the permissions management infrastructure, the subject devices would require occasional network connectivity to receive the updated ACLs, while in the case of receiving the ACLs indirectly, only the device receiving the ACL is required to have network connectivity.
- the subject devices may authenticate the guest devices and check the permissions granted to the guest devices by communicating directly with the permissions management infrastructure. For such functionality, the subject devices should have network connectivity at the time of authentication.
- the permissions management infrastructure 102 may generate permissions based on instructions of an owner, or based on requests from a guest (e.g. using PCE 106 ), while the permissions management infrastructure 102 may manage the generated permissions, and implement the permissions on a data processing device (e.g. guest device, subject device) in communication therewith or via a device associated with the owner (e.g. using the IDM 108 ).
- a data processing device e.g. guest device, subject device
- the permissions management infrastructure 102 may automatically generate new permissions based on various input data, and further implement the automatically generated permissions on various data processing devices (e.g. subject devices, envoy devices).
- various data processing devices e.g. subject devices, envoy devices.
- the input data may include one or more of the following taken alone or in combination:
- the owner may create a rule at the permissions management infrastructure 102 , whereby the rule is created by the owner e.g. via an application running on the owner's envoy device, and stored in database 111 at the permissions management infrastructure 102 .
- a rule/policy which an owner may use to set permissions is an IF: THAT; THEN THAT rule/policy, whereby as an illustrative example with reference to FIG. 10 a , the rule requires:
- THEN grant permission to the guest device to access all subject devices on the network having the same data type identifier.
- the guest device on being granted permission to access the alarm 20 g , the guest device will also be permitted to access the entry sensor 20 c and door lock 20 f , whereby the PCE 106 will generate the necessary permissions (e.g. as an ACL) and the IDM 108 will communicate corresponding certificates to the guest device to allow it to access the subject devices matching the criteria as before.
- the PCE 106 will generate the necessary permissions (e.g. as an ACL) and the IDM 108 will communicate corresponding certificates to the guest device to allow it to access the subject devices matching the criteria as before.
- household_appliance/ e.g. temperature sensor 20 a , light sensor 20 b , air conditioning unit 20 d , lightbulb 20 e
- security_appliance/ e.g. entry sensor 20 c , door lock 20 f , smart alarm 20 g
- a guest device 2 if a guest device 2 is permitted to access the temperature sensor 22 , the guest will automatically be permitted to access the temperature sensor 20 a , light sensor 20 b , air conditioning unit 20 d , lightbulb 20 e as a result of the owner created policy, whereby, for example, the PCE 106 will automatically generate the permissions and the IDM 108 will communicate the corresponding certificate(s) to the guest device 2 .
- the guest device 2 will not automatically be permitted to access the entry sensor, door lock and/or smart alarm as those devices comprise a different device class identifier, and the guest will have to request permission to access those subject devices.
- the PCE 106 may be configured to automatically grant permission for a guest device 2 to access all subject devices having the same device class identifiers (e.g. ‘household_appliance/’) if the owner grants permission to the guest device to access at least one subject device having that device class identifier.
- a device class identifier e.g. ‘household_appliance/’
- a lighting system (not shown) comprising a plurality of smart-lights installed in Cambridge city suddenly starts malfunctioning, due to the smart-lights having being compromised by malware such that hackers can control the smart-lights as they wish.
- Cambridge city technicians may have permissions to run local maintenance action on the smart-lights (e.g. to detect malware, identify faults) but not the permissions to install software e.g. to reinstall the operating system (OS) or reflash firmware.
- OS operating system
- An emergency rule set up at the permissions management infrastructure by the owner states that in the case of a subject device being compromised, the city technicians will be granted the necessary permissions to re-install the OS and/or reflash memory e.g. to eliminate local malware.
- the city technician may indicate that the smart-lights have been compromised (e.g. via an application on the envoy device), and therefore the PCE will automatically generate the permissions to allow all city technicians to install software and transmit the permissions to the technician's envoy device e.g. via the IDM.
- the PCE may also blacklist the hacker and create a blacklist of permissions (e.g. as an ACL) comprising details of the hacker (e.g. the network address of the hacker), which can be sent to all subject devices of the owner, e.g. via the permissions management infrastructure to prevent future access to a subject device by the hacker.
- a blacklist of permissions e.g. as an ACL
- details of the hacker e.g. the network address of the hacker
- the permissions management infrastructure may use information relating to guest identity as input data to automatically generate permissions.
- a guest may register with the permissions management infrastructure associated with an owner of subject devices e.g. by creating a guest account therewith via a web application.
- the guest may provide information relating to the guest identity and identity of any data processing devices associated with the guest to the permissions management infrastructure.
- information may include unique device identifiers and/or public keys of guest devices, which may be stored in database at the permissions management infrastructure.
- the owner may then set the permissions associated with the guest identity and the associated guest devices for the various subject devices of the owner.
- the PCE will generate permissions for the subject devices permitted to be accessed by the guest e.g. as ACLs comprising the unique device identifiers of the guest's data processing devices allowed to access the subject devices.
- the IDM will then transmit the ACLs to the subject devices directly or indirectly (e.g. as part of a certificate transmitted to the guest's data processing devices).
- the PCE 106 may automatically generate permissions for the new guest device to allow the guest access, through the new guest device, all subject devices which he was previously permitted to access by the owner.
- the owner may set a rule/policy which states that any new guest devices belonging to the guest will be provided with the same permissions as the guest's existing devices.
- the PCE may, for example using a machine learning algorithm (e.g. regression analysis), automatically generate permissions for guest devices and/or subject devices based on contextual information which may be derived from communications from subject devices, guest devices, owner devices within a network, or extracted from a database and used as input data.
- a machine learning algorithm e.g. regression analysis
- the device identifiers of subject devices and/or guest devices may provide contextual information e.g. where the device is located, who owns the device, what type of device does the owner intend to use the device as e.g. household appliance/security appliance.
- Such device identifiers may be communicated to the permissions management infrastructure by each of the subject devices directly or indirectly and stored within a database thereat.
- the PCE may recognise that an owner repeatedly sets the same permissions for subject devices having identical device identifiers within a certain location. Therefore, the PCE may be configured to automatically generate the same permissions for any new subject devices having the same device identifiers within the same area.
- an owner may purchase a temperature sensor subject device, turn it on e.g. within the secure zone of network.
- the owner when turning the temperature sensor on, the owner would use an owner envoy device to interact with the temperature sensor to, take ownership thereof and discover device identifiers and/or set the device identifiers and transmit the device identifiers to the permissions management infrastructure.
- the PCE would analyse the device identifiers provided by the envoy device and automatically generate permissions using the device identifiers and any contextual information as input data.
- a new subject device is a temperature sensor 22 and is located within the secure zone of the network 100 , comprising other subject devices 20 a and 20 b having identical device class identifiers, which are permitted, by the owner, to publish operational data to a website which can be accessed by the owner's family & friends.
- the PCE 106 will automatically generate permissions (e.g. as an ACL) for the new temperature sensor 22 to allow it to publish operational data to the website which can be accessed by the owner's family and friends.
- the IDM 108 may be used to manage implementation of the permissions on the new subject device, including obtaining owner consent to apply any automatically created permission by sending a proposal communication to owner e.g. via the owner's envoy, and managing the distribution of the permission to the subject device based on whether consent is received from the owner e.g. as a consent status communication. As before, the IDM 108 may upload permission to the new subject device 22 directly or indirectly e.g. via the owner's envoy device.
- the technician takes ownership of the smoke alarm via an envoy device and sets the device identifiers accordingly, and communicates the device identifiers to the PCE.
- the PCE will use the device identifiers set by the technician as input data and automatically generate a permission based on the context derived from the device identifiers.
- an example permission may be that the smoke alarm may only be locally accessed by a specific category of technician, for example by technicians being able to demonstrate Clean room 1 technician status e.g. by having a certificate signed with a Private key corresponding to such technicians, or, for example using an envoy device having a device identifier listed within an ACL on the smoke alarm.
- a further permission may be that the smoke alarm is to be accessible to certain external parties, e.g. by SCADA1 system.
- the IDM may then push the permission to ‘MR Y's’ envoy device which, in turn, pushes the permission to the smoke alarm detector for implementation thereon.
- An owner may also update permissions for subject devices/guest devices at the permissions management infrastructure.
- the guest device may be configured to automatically check with the permissions management infrastructure as to whether there are any updates to the existing permissions, and the IDM can push any updated permissions to the guest device or to the subject device.
- the guest device may automatically check with the permissions management infrastructure if there are any updated permissions for the guest device e.g. to extend the permissions.
- the IDM 108 can automatically push the updated permissions to the guest device.
- updated permissions may be set by the owner, and stored within a database 111 .
- an owner may modify the permissions associated with certain subject devices, e.g. the owner may change the location that a subject device is to publish data to and/or may prohibit certain guest devices accessing the subject devices.
- the modified permissions may then be transmitted to the permissions management infrastructure 102 .
- the PCE may generate updated ACLs having the updated permissions and the IDM will manage the distribution accordingly. If the IDM cannot communicate the updated permissions to the subject device directly or indirectly, e.g. due to lack of connectivity, the permissions may be stored in the database until connectivity becomes available.
- the envoy device may check with the permissions management infrastructure as to whether there are any updated permissions for the subject device, and the IDM may push the updated permissions in the database to the envoy device, which in turn will push the updated permissions to the subject device e.g. via BLE.
- the subject devices are not required to be connected to the cloud to receive updated permissions, but can receive permissions via various data processing devices in proximity thereto (e.g. guest devices and/or owner envoy devices etc.).
- the owner may transmit a description of ownership to the permissions management infrastructure, whereby the description of ownership may comprise the device identifiers of the subject device.
- the owner may, for example using an application running on the owner envoy device, create groups into which subject devices may be classified, whereby each of the groups may have associated rules at the permissions management infrastructure as defined by the owner.
- the PCE may automatically generate access permissions depending on the defined rules, and the IDM may distribute the permissions accordingly.
- the owner may create a ‘private’ group, and further create a rule at the permissions management infrastructure whereby subject devices classified as being within the ‘Private’ group are to be inaccessible to data processing devices other than those belonging to the owner.
- the owner may define a ‘public’ group, and further create a rule whereby subject devices classified as being within the ‘Public’ group are accessible by any data processing device whatsoever.
- the owner may define further groups and define any associated rules dependant on the requirements of the particular owner.
- groups may include, a ‘Friends’ group, a ‘Family’ group, an ‘Employees of Company X’ group, ‘Temporary Employees group’ etc.
- the permissions management infrastructure may communicate with a remote resource such as a remote directory service e.g. an address book on the owner's mobile device, a server database, and/or a web application to identify such data processing devices e.g. by device identifiers listed in the directory (e.g. a device owner identifier).
- a remote directory service e.g. an address book on the owner's mobile device, a server database, and/or a web application to identify such data processing devices e.g. by device identifiers listed in the directory (e.g. a device owner identifier).
- the permissions management infrastructure may readily generate permissions for multiple subject devices and transmit the permissions to multiple guest devices, whereby, for example, the PCE may be used to generate the permissions, and the IDM used to distribute the permissions to the appropriate devices.
- FIG. 11 a shows an example of an owner taking ownership of a new subject device 22 , which in the present example is depicted as a music player 22 .
- the ownership procedure may be undertaken by transmitting the owner's public key Puk (Owner) to the music player 22 from the owner's envoy device 1 .
- the owner defines a ‘Friends’ group at the permissions management infrastructure e.g. via an application on the envoy device 1 , and further defines a rule that any data processing devices belonging to a friend e.g. via an envoy device owned by a friend, hereinafter “friend device”, is permitted to access the music player 22 .
- the permissions management infrastructure 102 communicates with remote directory service 130 , which in the present example is a web application comprising a list of all the owner's friends and their associated friend devices 2 a - 2 n.
- the PCE 106 may automatically generate permissions for all friend devices, and the IDM 108 may automatically communicate the permissions to each of the friend device 2 a - 2 n.
- all the owner's friends may via their respective friend device 2 a - 2 n access the music player 22 as described above, and, for example control which music is played by the music player 22 , and listen to the tunes played on the music player 22 .
- FIG. 11 b schematically illustrates an example of an owner blacklisting a friend device 2 b.
- friend device 2 b is blacklisted by the owner, whereby the friend is removed from the friends list. As such the owner notifies the permissions management infrastructure 102 , e.g. via an application on the envoy device 1 .
- the permissions management infrastructure may periodically check with the remote directory service 130 as to whether there are any updates to the group.
- the PCE 106 may then notify the music player 22 of the change in permissions, e.g. by pushing an updated ACL comprising the blacklisted device identifier (e.g. the public key of the friend device 2 b ) to the music player 22 . Therefore, any request to access the music player by friend device 2 b will be denied.
- the blacklisted device identifier e.g. the public key of the friend device 2 b
- permissions to specific devices within user defined groups may be easily revoked, while without revoking permissions for all devices within the group.
- PCE and IDM are shown to be discrete elements within the permissions management infrastructure above, it will be appreciated that the PCE and IDM may be implemented using any suitable configuration.
- the PCE and IDM may be provided as part of the same processing engine running on a single server.
- the PCE and IDM may be implemented as different data processing engines running on the same server or the PCE and IDM may be implemented as processing engines on remote servers in communication with each other.
- the subject devices are not required to be located in a home or work environment, and may be distributed in any network configuration as required by the owner e.g. throughout a building, a business park, a town, a country, a continent or worldwide. Furthermore, there is no requirement for the subject devices to be within the same network.
- an owner is taken to be a party authorized to access the subject devices and may be a single party or an owner may comprise multiple parties.
- an owner may be a homeowner having the subject devices in his/her home.
- the owner may be a team of employees of a business which legally owns the subject devices, whereby, for example, the team of employees interact with the subject devices on behalf of the legal owner.
- a method of creating, at a permissions management resource, access permissions relating to a subject device for at least one data processing device comprising: obtaining, at the permissions management resource, input data; generating, at the permissions management resource, at least one permission relating to accessing the subject device in response to the input data; transmitting, from the permissions management resource to the subject device or the at least one processing device, a communication comprising the at least one permission.
- the input data may comprise permissions set by an authorized party and/or the input data may comprise at least one of: a rule/policy defined by an authorized party; a device attribute of the at least one data processing device; a device attribute of the subject device, and/or contextual information.
- the input data may comprise classification data relating to the subject device, wherein the classification data may relate to a group within which the subject device is classified by the authorized party.
- the method may further comprise: generating, at the permissions management resource, a communication comprising a request for at least one device attribute associated with the group; transmitting the communication comprising the request to a remote directory service; receiving, at the permissions management resource from the remote directory service, the device attribute relating associated with the group.
- Generating at least one permission in response to the input data may comprise: automatically generating the at least one permission at the permissions management resource; transmitting, from the permissions management resource, a permission proposal communication to an authorized party, wherein the permission proposal communication may comprises data relating to the automatically created at least one permission; receiving at the permissions management resource, a consent status communication in response to the permission proposal communication and transmitting the communication comprising the at least one permission to the subject device is based on the consent status communication.
- Transmitting the communication comprising the at least one permission may comprise transmitting the communication directly or indirectly to the subject device or the at least one data processing device.
- the at least one permission may comprise a certificate and/or an access control list, wherein the certificate may further comprise a credential associated with the at least one data processing device, wherein the credential associated with the data processing device may comprise a first cryptographic key, wherein the first cryptographic key may be associated with the at least one data processing device, wherein the first cryptographic key may comprise a public key of the at least one data processing device.
- the certificate may further comprise a credential associated with an authorized party, wherein the credential associated with the authorized party may comprise a second cryptographic key, wherein the second cryptographic key may be associated with the authorized party, wherein the second cryptographic key may comprise a private key of the authorized party.
- the method further may further comprise: generating, at the permissions management resource, a blacklist of permissions; transmitting, from the permissions management resource, a communication comprising the blacklist of permissions to the subject device.
- a permissions management resource for creating permissions relating to a subject device, the permissions management resource comprising: a permission creation engine configured to generate permissions based on input data; and an identity management engine configured to manage the permissions generated at the permission creation engine and to communicate the permissions to the subject device or at least one data processing device directly or indirectly.
- the input data may be set by an authorized party, wherein the input data may comprise at least one of: a rule/policy defined by an authorized party; a device attribute of at least one data processing device; a device attribute of the subject device, and/or contextual information, wherein the permission creation engine may be configured to automatically generate the permissions based on the input data.
- the method may comprise: generating, at the data processing device, a request communication comprising a request to access the subject device; transmitting, from the data processing device to a permissions management resource, the request communication; receiving, at the data processing device, from the permissions management resource, a permissions communication comprising at least one permission relating to the subject device in response to the request communication.
- Transmitting the request communication may comprise, transmitting the request communication directly or indirectly to the permissions management resource.
- Receiving the permissions communication may comprise, receiving the permissions communication directly or indirectly from the permissions management resource.
- the method may further comprise: transmitting, from the data processing device to the subject device, the at least one permission.
- the at least one permission may comprise a certificate, wherein the certificate may comprise a credential associated with a resource authorized by the subject device and/or wherein the certificate may comprise a credential associated with the data processing device and/or wherein the certificate may comprise an access control list.
- the method may further comprise: receiving, at the data processing device from the permissions management resource, a blacklist of permissions and transmitting, from the data processing device to the subject device, the at least one permission.
- a method of claiming ownership of a subject device comprising: receiving, at the subject device, a communication comprising a credential from a resource remote therefrom; storing, within storage circuitry at the subject device, the credential; and associating the credential with an owner of the subject device.
- the remote resource may comprise a data processing device associated with the owner and/or the remote resource may comprise a permissions management resource.
- the credential may comprise a cryptographic key.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
Abstract
Description
- This application is a continuation of application Ser. No. 15/001,750 filed Jan. 20, 2016, which claims priority to GB Application No. 1501027.5 filed Jan. 21, 2015, each of which is hereby incorporated herein in its entirety by reference.
- The technical field relates to data processing devices and in particular to creating permissions and managing permissions for data processing devices.
- There are ever increasing numbers of devices within the home, other buildings or the outdoor environment that have processing and communication capabilities which allow them to interact with other processing devices.
- Everyday objects and relatively small scale data processing devices, hereinafter “subject devices” may be connected to each other and to central resources as part of the “Internet of Things” (IoT).
- For example, a temperature hub in a home environment may gather information from various subject devices, such as temperature sensors around the home, and control the activation of heaters/air conditioning units based on the gathered information. Furthermore, the subject devices may generate information thereon, e.g. information relating to energy usage, efficiency, which may be sent to a cloud service and accessed by an interested party e.g. via a web application.
- Furthermore, a subject device, such as an entry sensor in a smart-door, may gather authorization information from a data processing device in communication therewith and control the activation of an associated door lock based on the authorization information. The subject device may generate information thereon e.g. information relating to entry attempts, which may be sent to a cloud service to be accessed by a party.
- However, since many subject devices have little processing capability, and may only have intermittent network connectivity or connectivity with high latency, due to energy or connectivity constraints, establishing a trusted relationship with other data processing devices remote therefrom can be difficult and may significantly increase the cost and complexity of the IoT and/or data processing devices.
- The present techniques seek to address these problems.
-
FIG. 1 schematically shows an example of a data processing device for use with the present techniques; -
FIG. 2 schematically shows an example of a subject device which can communicate with the data processing device ofFIG. 1 ; -
FIG. 3 schematically shows the data processing device ofFIG. 1 in a network; -
FIG. 4 schematically shows the data processing device ofFIG. 1 communicating with a subject device to take ownership thereof; -
FIG. 5 schematically shows the data processing device ofFIG. 1 communicating with a subject device to access features of the subject device; -
FIG. 6 schematically shows a guest data processing device in a network communicating with a subject device; -
FIG. 7a schematically shows an owner granting permission to the guest data processing device ofFIG. 6 to access a subject device using a permissions management infrastructure; -
FIG. 7b schematically shows an owner, using the data processing device ofFIG. 1 , granting permission to the guest data processing device ofFIG. 6 to access a subject device; -
FIG. 8 schematically shows the guest data processing device ofFIG. 6 communicating with a subject device; -
FIG. 9 schematically shows a permissions management resource; -
FIG. 10a schematically shows the guest data processing device ofFIG. 6 in a network communicating with a plurality of subject devices; -
FIG. 10b schematically shows the guest data processing device in a network communicating with a plurality of subject devices; -
FIG. 11a schematically shows a plurality of data processing devices in a network communicating with a permission management infrastructure; and -
FIG. 11b schematically shows the plurality of data processing devices in a network communicating with the permission management infrastructure ofFIG. 11 a. -
FIG. 1 , schematically shows an example of adata processing device 1 for use with the present techniques. In the present examples, thedata processing device 1 may comprise credentials relating to an authorized party associated with the data processing device 1 (e.g. an owner), which may be used to verify the identity of the owner to other resources remote therefrom e.g. data processing devices, applications running on remote devices, cloud platforms, directories etc. - The
data processing device 1, which may comprise credentials, hereinafter “envoy device” may also be capable of running applications to process data received from any such remote resources in order to access, interact with and/or verify the identity and/or to take ownership thereof on behalf of the owner. - Furthermore, the
envoy device 1 may be capable of defining permissions associated with data processing devices which the owner has taken ownership of, and communicating such permissions to any such data processing device. - As illustrated in
FIG. 1 , theenvoy device 1 may comprise aprocessing element 3 coupled to astorage element 4, comprising, for example memory circuitry (volatile memory (V) & non-volatile memory (NV), such as such as flash and ROM). Thememory circuitry 4 may store programs executed by theprocessing element 3. - In the present example, a non-volatile memory region (NV) may be both read from and written to, but for which read and/or write protection may be applied so that a protected region (not shown) of NV can only be accessed by privileged software executed by the
processing element 3. The protected region may store confidential information such as device identifiers, cryptographic keys, certificates, e.g. comprising permissions such as an access control list (ACL) therein. - In the present example, the protected region may also comprise a device identifier, such as a unique device identifier which uniquely identifies the
envoy device 1. The unique device identifier may take any suitable form, and may for example be a semantic identifier defined by an owner, an IPv6 address, IPv4 address, serial number, Universally Unique Identifier (UUID) or Globally Unique Identifier (GUID) etc. - The
envoy device 1 also comprisescommunication circuitry 6 for communicating with remote data processing devices/resources (not shown inFIG. 1 ). Thecommunication circuitry 6 may use awireless communication 7, such as, for example, wireless local area network (WiFi), short range communication such as radio frequency communication (RFID), near field communication (NFC) or communications used in wireless sensor networks such as ZigBee, Bluetooth and/or Bluetooth Low energy (BLE). Also thecommunication circuitry 6 may use a cellular network such as 3G or 4G. Thecommunication circuitry 6 may also, in some examples, use wired communication such as a fibre optic or metal cable (not shown). Thecommunication circuitry 6 could also use two or more different forms of communication, such as several of the examples given above in combination. - The
envoy device 1 may also comprise input/output (I/O)circuitry 8 such as a user interface (UI) (e.g. buttons) to allow the owner to interact with theenvoy device 1. Furthermore, theenvoy device 1 may comprise adisplay 9 e.g. an organic light emitting diode (OLED) display, for communicating messages to the owner. The display may also be a touch screen to receive inputs from the owner. - Although, the
envoy device 1 may comprise large scale data processing devices such as a tablet computer, often theenvoy device 1 comprises a relatively small scale data processing device such as a smartphone or a wearable data processing device, for example a smart-watch. - It will be appreciated that the
envoy device 1 may comprise other hardware/software components not described herein depending on the specific function of theenvoy device 1. For example, in the case of a smart-watch, theenvoy device 1 may comprise a global positioning system (GPS) to capture and record movement, and to generate operational data accordingly. -
FIG. 2 schematically shows an example of asubject device 20 which can communicate with an envoy device using the present techniques. - The
subject device 20 may be any device which gathers data for transmitting to a remote resource (e.g. theenvoy device 1, web application), which may verify credentials received from a remote resource and/or which may be accessed by a remote resource. For example, thesubject device 20 may be a connected device in the Internet of Things (IoT) such as a wireless sensor or actuator. - In the present illustrative example, the
subject device 20 comprises aprocessing element 21, andstorage element 24, comprising, for example memory circuitry 24 (e.g. volatile memory (V) and/or non-volatile memory (NV), such as such as flash and ROM). - The
memory circuitry 24 may store programs executed by theprocessing element 21. - In the present example, the
memory circuitry 24 comprises a NV memory region which can be both read from and written to, but for which read and/or write protection may be applied so that the protected region (not shown) of NV can only be accessed by privileged software executed by theprocessing element 21. The protected region may store confidential information, for example cryptographic keys, ACLs or certificates received from a resource remote therefrom, such as anenvoy device 1, or a cloud service. - In the present example, the protected region also comprises a device identifier, such as a unique device identifier which uniquely identifies the
subject device 20. The unique device identifier may take any suitable form, for example as described above. - The
memory circuitry 24 may also comprise further device identifiers which correspond to attributes associated with thesubject device 20. - For example, device type identifiers may provide further information about the
subject device 20, whereby the device type identifiers may include, for example, a device manufacturer identifier (e.g. ‘Made_by_CompanyY’), an owner identifier (e.g. ‘Owner_is_Alice’), a device class identifier (e.g. ‘temperature_sensor’), and/or a device location identifier (e.g. ‘living_room’). - Furthermore, device capability identifiers may provide information relating to the specific functionality of the subject device such as, for example a text description of the device functionalities e.g. ‘Subject device can measure temperature’, ‘Subject device can authorise received credentials and unlock connected doors,’ ‘Subject device can publish data on the Internet via web applicationXYZ’.
- The device identifiers may also comprise data type identifiers relating to the type of data generated by the device. For example, in the case of a temperature sensor, the data type may be classified as ‘low_sensitive_data,’ while in the case of an entry sensor, the data type may be classified, for example as ‘high_sensitive_data’ or ‘secret_data’.
- The device identifiers may be hierarchical in form, whereby, a device identifier may have different levels associated therewith.
- As an illustrative example, in the case of a device location identifier located in a user's kitchen, the location identifier may comprise multiple levels ‘house/downstairs/kitchen.’
- As a further illustrative example of a device location identifier having multiple levels, a device belonging to a company may comprise the device location identifier ‘CompanyY_HeadQuarters/Building6/2ndFloor/Office8’
- As a further example, a device class identifier may take the hierarchical form, to provide multiple levels of device class identifier. As an illustrative example, a temperature sensor in a house may comprise the device class identifier: ‘household_appliance/sensor/temperature_sensor’, while an entry sensor may, for example, comprise the device class identifier ‘security_appliance/sensor/entry_sensor’.
- It will be appreciated that while certain device identifiers may be permanently written to memory on a subject device e.g. at manufacture, such as the device class identifier (e.g. sensor/temperature_sensor) device manufacturer identifier (Made by ACMESensor's Ltd′), and/or the unique device identifier (e.g. an IPv6 address), an authorized party e.g. an owner, may set other device identifiers, or add hierarchical levels to the device identifiers.
- For example, in a home environment, the owner may set whether the subject device should be designated a ‘security_appliance’ or a ‘household_appliance’, who the owner is, and/or the owner may classify the type of data generated by the device e.g. ‘high_sensitive_data’ or ‘low_sensitive_data’.
- The owner may, for example, set the device identifiers via an application running on an envoy device in communication with the subject device.
- Therefore, it will be appreciated that in addition to providing information relating to device attributes, the device identifiers may also provide contextual information relating to how the owner intends to use the device.
- The
subject device 20 may also comprisecommunications circuitry 26 for communicating with remote data processing devices and/or resources, such as envoy devices, or cloud services, to receive requests/commands/credentials/permissions (e.g. in an ACL) therefrom or to push data thereto.Such communications circuitry 26 may includewireless communications 27 e.g. BLE, Bluetooth, ZigBee, WiFi, and/or cellular 3G/4G. - The
subject device 20 may further comprise I/O circuitry 28, such as sensing circuitry to sense inputs from the surrounding environment to generate operational data and/or to provide an output to control an operation of thesubject device 20 e.g. to control a transistor to determine the operation of a buzzer, a light emitting diode(s) or a relay (not shown). - For example, the
subject device 20 may be a smart-lightbulb comprising an array of LEDs, whereby an owner may control the emission the LEDs via an application running on a remote device. - Alternatively, the
subject device 20, may be an embedded device such as a healthcare monitor, which generates operational data related to its owner's health such as heart rate, blood sugar level and/or temperature and sends the operational data to a remote server for processing of the operational data, which may then be accessed by the owner, or a select group of users authorized to access the operational data by the owner. - Alternatively, the
subject device 20 may be an embedded temperature sensor, which generates operational data based on the temperature of the surrounding environment, and publishes the operational data on a web application on behalf of its owner. - Alternatively, the
subject device 20 may be a smart fridge, which detects, for example, the date of expiry on foodstuff therein and alerts the owner via an application running on the owner's smart-phone if any food is approaching expiry. - Alternatively, the
subject device 20 may be an entry sensor on a smart door, which is operable to lock/unlock the door based on communications received from a data processing device. - Alternatively, the
subject device 20 may be a wearable device, for example a fitness band which generates data relating to movement, for example capturing distance walked/run/swam, or elevation ascended/descended. - Alternatively, the
subject device 20 may be a smart-pen, configured to generate operational data relating to the specific movement of the pen, for example alphanumeric characters or pictures. Thesubject device 20 may also be configured to create files such as JPEG/Vector (e.g. SVG)/Portable Document Format (PDF) recording the specific movements, and to send the data to a remote server for processing of the operational data. - It will be appreciated that subject devices listed above are by way of example only. It will further be appreciated that subject devices may comprise other hardware/software components not described herein depending on the specific function of the subject device.
- Furthermore, while an envoy device as described above may be capable of providing similar functionalities as a subject device, in that an envoy device may sense inputs, process data, and communicate with resources remote therefrom, it will be appreciated that envoy devices will generally have increased processing capabilities in comparison to subject devices, and be capable of providing increased functionalities and greater interaction with a user in comparison to subject devices. For example, as described above, the envoy device may comprise a mobile phone or a smart watch, with which a user can interact, e.g. via a plurality of applications running thereon.
-
FIG. 3 schematically illustrates an example of asystem 99 comprisingenvoy device 1 communicating with a plurality ofsubject devices 20 a-20 g in a local network 100 (e.g. within a home network or office environment); whereby theenvoy device 1 is in communication with apermissions management resource 102 remote therefrom, whereby thepermissions management resource 102 is configured to manage the generation and distribution of commands, credentials and/or permissions for data processing devices (e.g. the envoy devices/subject devices). - In the following illustrative examples, the
permissions management resource 102 is described as a cloud platform on an external network 104 (e.g. the internet), in communication with envoy devices/subject devices located in a local network 100 (e.g. a mesh network). However, thepermissions management resource 102 is not limited to being a cloud platform, and may be provided as a data processing device within thelocal network 100, or an application running thereon. - In the present examples, the
envoy device 1 is taken to belong to an owner of thesubject devices 20 a-20 g, i.e. a party who is authorized, for example, to have unrestricted access to the subject devices e.g. to configure/set permissions/control the subject device. - The
envoy device 1 may communicate with thesubject devices 20 a-20 g using any suitable communications protocol (e.g. Bluetooth/BLE/ZigBee), while theenvoy device 1 may communicate with thepermissions management infrastructure 102 using any suitable communications protocol (e.g. BLE, ZigBee, WiFi, cellular 3G/4G). - The
envoy device 1 may also communicate with thepermissions management resource 102 using intermediate devices such as routers (e.g. border routers/Internet Service Provider (ISP) routers). - The subject devices may also communicate with each other, to control the functionality thereof (e.g. via BLE, Zigbee, wired etc.), whist the subject devices may also communicate with the
permissions management infrastructure 102 directly (e.g. via WiFi, cellular 3G/4G) using intermediate devices as required, or indirectly e.g. viaenvoy device 1 or a further data processing device. - In the following examples the permissions management resource is depicted as a
permissions management infrastructure 102 on the cloud comprising a data processing engine 106 (e.g. software running on a server located on the cloud), hereinafter referred to as a permission creation engine (PCE) 106, which is configured to generate permissions for resources such as data processing devices (e.g. envoy devices, subject devices), applications and/or system processes, whereby the generated permissions may be defined by an owner of the resource at thepermissions management infrastructure 102 e.g. via an application running on the owner'senvoy device 1 or on another data processing device in communication with thepermissions management infrastructure 102. The permissions defined by the owner may then be generated at thepermissions management infrastructure 102 usingPCE 106. - For example the owner may define what functions a particular subject device is permitted to undertake, or where a subject device should publish information on behalf of its owner. Additionally or alternatively, the owner may define the amount of access a guest device is permitted to have with respect to the features and/or functionality of one or more subject devices, and the owner may also define the limits of any such access and/or the duration thereof.
- Additionally or alternatively, permissions may be automatically generated by the
PCE 106 based on an analysis of input data comprising rules/policies (predefined or customized by an authorized party), contextual data and/or guest identity. Such functionality is described in greater detail with relation toFIGS. 9 and 10 ). - The
permissions management infrastructure 102 may also comprise identity management engine (IDM) 108 (e.g. software running on a server located on the cloud), which is configured to manage the permissions generated at thePCE 106, e.g. by distributing the permissions to one or more data processing devices (e.g. a subject device and/or envoy devices) so the permissions can be implemented on the data processing devices. - In the present examples, the generated permissions comprise an access control list (ACL), whereby an ACL may define the functionality which the subject device is authorized to undertake.
- For example, according to an example ACL, a subject device may be configured to control other subject devices e.g. an entry sensor may be permitted to unlock a door or to activate an alarm, while a temperature sensor may be permitted to adjust the output of an air-conditioning unit. In a further example, an ACL may specify the location of a web page or a server to which any operational data generated by a subject device should be pushed.
- As an illustrative example, an ACL may specify whether any data processing devices are authorized to access features/functionality of a subject device. For instance, a subject device may be provided with an ACL which contains the instructions:
-
- ‘Guest_Device_X: read, write—file A; and
- Guest_Device_Y: read—file B’
- Therefore a subject device having such an ACL may permit ‘Guest Device X’ to read and write from/to the file A on the subject device, while the ACL may permit ‘Guest Device Y’ to only read from file B on the subject device.
- Additionally or alternatively, the ACL may comprise a list of specific permissions relating to activities which the owner permits a guest device to undertake, e.g.
-
- ‘Guest device X: read, write—File A: Monday to Friday 0900-1700; and
- Guest device Y—read file B Tuesday to Thursday’
- Additionally or alternatively, an ACL may have an expiration period, after which the ACL is no longer valid. For example, an ACL on a subject device may be valid for a period of 24 hours, whereby a guest device may be permitted to access the subject device during the period the ACL is valid, but whereby the guest device will not be able to access the subject device after that period, and will have to request an updated ACL.
- Furthermore, a subject device may utilise a blacklist of permissions, which, for example, may comprise an ACL comprising details of functions prohibited to be performed by the subject device (e.g. do not generate data after 1900 hrs).
- Additionally or alternatively, the blacklist of permissions may comprise details (e.g. device identifiers, public keys, network addresses) of data processing devices/applications/resources prohibited from accessing the subject device.
- The owner may, via envoy device or another data processing device, define the details and/or functions to be included within the blacklist, and may further define which subject devices should implement the blacklist. The
PCE 106 may then generate the blacklist, while theIDM 108 may communicate the blacklist to the subject devices directly or indirectly. - Such functionality allows the owner to prevent unauthorized access to subject devices, for example by
rogue 3rd parties. - In the illustrative example schematically shown in
FIG. 3 ,subject devices 20 a-g, are owned by the same owner, which also ownsenvoy device 1, whereby: -
Subject device 20 a is depicted as a temperature sensor configured to detect the temperature of the surrounding environment and to generate operational data based on the sensed temperature. -
Subject device 20 b is depicted as alight sensor 20 b configured to detect levels of light in the surrounding environment, and to generate operational data based on the sensed levels. -
Subject device 20 c is depicted as anentry sensor 20 c, configured to communicate with other data processing devices and to determine the authorization of such devices. -
Subject device 20 d is depicted as anair conditioning unit 20 d, having functionality (e.g. heat/cool output), which may be controlled by a data processing device in communication therewith. -
Subject device 20 e is depicted as a smart lightbulb, having functionality (e.g. on/off, dimming), which may be controlled by a data processing device in communication therewith. -
Subject device 20 f is depicted as a smart door lock, having functionality (e.g. lock/unlock), which may be controlled by a data processing device in communication therewith. -
Subject device 20 g is depicted as a smart alarm having functionality (e.g. sound buzzer) which may be controlled by a data processing device in communication therewith. - In the present example, the
temperature sensor 20 a,air conditioning unit 20 d,light sensor 20 b andlightbulb 20 e andalarm 20 g are considered to be part of a secure zone within network 100 (e.g. within the interior of an owner's home), while theentry sensor 20 c and door lock 20 f are considered to be part of a non-secure zone within the local network 100 (e.g. at the exterior of the owner's home), with the boundary between secure and non-secure zones depicted as 110. It will be appreciated that, in some examples, theboundary 110 may not necessarily be a physical boundary. - As before, the owner may, via an application running on the
envoy device 1, set permissions at thePCE 106 for each of thesubject devices 20 a-g. ThePCE 106 may generate an ACL corresponding to the permissions set by the owner, whereby any ACL is transmitted to the subject devices byIDM 108 directly (e.g. via WiFi) or indirectly e.g. viaenvoy device 1, whereby the ACL will be implemented thereon. - For example, the owner may set permissions at the
PCE 106 to instruct thetemperature sensor 20 a to push all operational data generated thereon to a specific web service on the internet. Additionally or alternatively, the permissions may relate to communicating with another data processing device, whereby, for example, the owner instructs thetemperature sensor 20 a to send operational data to theair conditioning unit 20 d. - Furthermore, the owner may also set permissions for the
air conditioning unit 20 d at the PCE, whereby, for example, the owner instructs theair conditioning unit 20 d to accept operational data from thetemperature sensor 20 a, and perform an action accordingly, such as “maintain temperature at 19° C.”, “power off between 0101 and 0830.” - Therefore, in the example above, the
temperature sensor 20 a will generate operational data and send the operational data to theair conditioning unit 20 d. As theair conditioning unit 20 d is permitted to receive data from thetemperature sensor 20 a, the operational data will be processed and the output of theair conditioning unit 20 d adjusted according to the instructions in the ACL. - As a further illustrative example, the owner may set permissions at the
PCE 106 to allow thelight sensor 20 b to push all operational data generated thereon to a web service on the cloud for access by any interested party. ThePCE 106 will generate an ACL corresponding to the permissions set by the owner, whereby the ACL is transmitted to thelight sensor 20 b byIDM 108, e.g. viaenvoy device 1. - As a further illustrative example, the owner may set permissions at the
PCE 106 to allow theentry sensor 20 c to authorise access to certain guests (e.g. as described below) and on authorizing the guests to push all operational data generated thereon (e.g. capturing the date and time and guest identification) to a web service on the cloud for access by the owner. - Additionally or alternatively, the permissions may relate to communicating with another data processing device(s), whereby, for example, the owner instructs the
entry sensor 20 c to send command instructions to theair conditioning unit 20 d,light bulb 20 e,door lock 20 f and orsmart alarm 20 g based on the operational data. - Furthermore, the owner may also set permissions for the
air conditioning unit 20 d,lightbulb 20 e,door lock 20 f and/orsmart alarm 20 g at the PCE based on instructions received from theentry sensor 20 c, whereby, for example, the owner instructs theair conditioning unit 20 d,lightbulb 20 e and door lock 20 f to perform respective actions, such as for example: -
- For the door lock—“if instructed by entry sensor—open door”;
- For the air conditioning unit—“if instructed by entry sensor—power on and maintain 19° C.”.
- For the smart lightbulb—“if instructed by entry sensor—turn on”; and/or
- For the smart alarm—“if instructed by entry sensor—activate buzzer”
- Therefore, in the example above, the
entry sensor 20 a will authorise a guest to enter the house and, on doing so, may instruct thedoor lock 20 f to unlock, theair conditioning unit 20 d to turn on and maintain 19° C., and/or instruct thelight bulb 20 e to turn on. - Alternatively, if a guest in not authorized to enter the house, the entry sensor may instruct the
smart alarm 20 g to activate the buzzer, and instruct thelightbulb 20 e to turn on. - Therefore, it will be appreciated that the owner may, using the
permissions management infrastructure 102, define the permissions for a particular subject device and manage the implementation of the permissions on the subject devices. ThePCE 106 may generate an ACL specifying the permissions set by the owner, whereby theIDM 108 may manage the distribution of the ACLs to the respective subject devices, whereby the subject devices are configured to perform the operations specified in the ACLs. - As will be appreciated, the permissions may be transmitted directly to the subject devices from the
permissions management infrastructure 102. Therefore, using such functionality, the subject devices may be required to have a constant network connection to receive the ACLs. - Alternatively, the permissions may be transmitted to the subject devices indirectly e.g. via the
owners envoy device 1 or a data processing device. In such a case theenvoy device 1 may receive the ACL from theIDM 108 and transmit the ACL to the to the subject device when in proximity thereto, e.g. using BLE. Using such functionality, the subject device is not required to have a constant network connection, and can receive any permissions locally over a suitable communications protocol. - The subject devices may verify that the permissions are transmitted thereto by an authorized device and/or resources using any suitable verification protocol. For example, cryptographic keys (e.g. symmetric/asymmetric keys) may be used for verification purposes. Such keys may be 128-bit or 256-bit AES (Advanced Encryption Standard) keys or elliptic curve cryptography (ECC) keys.
- For example, when using asymmetric keys, the
subject devices 20 a-20 g may comprise a public key of the owner Puk(Owner) and/or the public key of the permissions management infrastructure Puk(PMI) stored in memory thereon. - The public keys may be provided to the subject devices during a registration process between the owner and the respective subject devices, e.g. using the owner's
envoy device 1, whereby the subject devices may recognise any public keys provided thereto during the registration process as being associated with its owner, or a party authorized by its owner to interact therewith. Furthermore, a subject devices may also send the owner its public key e.g. during the registration process. - Therefore, the owner and/or
permissions management infrastructure 102 may sign the ACL with their respective private keys before sending the ACL to the subject device, and, before implementing the ACL, the subject device may verify that the ACL is from an authorized party by verifying the signature using the corresponding public key(s). - Furthermore, the owner, may send a description of any subject devices which it has taken ownership of to the
permissions management infrastructure 102, such that thepermissions management 102 is aware of the subject devices. The description of ownership may comprise the device identifiers of the respective subject devices and or the respective public keys thereof. - It will be appreciated that as the owner and/or the permissions management infrastructure comprise the public key Puk(Subject) of the subject device, communications from the
envoy device 1/permissions management infrastructure 102 may be encrypted using the public key Puk(Subject) of the subject device to which permissions are to be sent, whereby the subject device can decrypt the communications using the corresponding private key Prk(Subject). - The owner may also add new subject devices to the network and take ownership thereof. As shown in the illustrative example of
FIGS. 3 and 4 , on powering on a new subject device 22 (which is depicted as a 2nd temperature sensor), the newsubject device 22 may broadcast its attributes (e.g. device identifiers) and broadcast it's availability for an owner to take ownership thereof (as shown atStep 200FIG. 4 ). - The owner may, via an application running on the
envoy device 1, take ownership of the newsubject device 22, whereby for example, a credential associated with the owner and/or an authorized party is communicated to thesubject device 22 and stored in memory circuitry provided thereon, whereby the credential is taken to be that of the owner. - In the present example, the credential is a public key (Puk(Owner)) of an asymmetric key pair of the owner, whereby Puk(Owner) is received by the new
subject device 22 and stored in a protected region of memory thereat, and taken to be the public key of its owner (Step 202). The newsubject device 22 may transmit a communication to theenvoy device 1 to confirm receipt of the credential and that the owner has taken ownership thereof (Step 204). As above, such a communication may comprise the device identifiers of thesubject device 22. Furthermore, the owner, may send a description of ownership to thepermissions management infrastructure 102, such that thepermissions management 102 is aware of thesubject device 22. - The corresponding cryptographic key e.g. a private key (Prk(Owner)), of the owner may be stored within the protected region at the
envoy device 1. In some examples, the private key (Prk(Owner)) may be communicated to thepermissions management infrastructure 102 and stored thereat e.g. at a protectedregion 109 of theIDM 108. The private key Prk(Owner) may be provided to thepermissions management infrastructure 102 during a registration process between the owner andpermissions management infrastructure 102. - As before, the new
subject device 22 may comprise device identifiers provisioned thereon at manufacture and/or which are set by the owner on taking ownership of the newsubject device 22 e.g. via an application. -
FIG. 5 shows an example of an owner interacting with the newsubject device 22 usingenvoy device 1. Having taken ownership of the newsubject device 22, the owner may be able to access the newsubject device 22 using theenvoy device 1. - At
step 210 the owner may, viaenvoy device 1, request to access the newsubject device 22. - At
step 212, the newsubject device 22 may generate and transmit a communication comprising a cryptographic nonce to theenvoy device 1, whereby theenvoy device 1 signs the nonce with the owner's private key (Prk(Owner)). - At
step 214, the signed nonce is transmitted to the newsubject device 22, which verifies the signature using the owner's public key (Puk(Owner)) stored thereon, whereby, on verification of the signature, theenvoy device 1 is granted access to the new subject device 1 (Step 216). -
FIG. 6 shows an example of aguest envoy device 2, hereinafter “guest device” 2 added to thenetwork 100 within thesystem 99, whereby a guest requests, via theguest device 2, permission to access one or more subject devices (20 a-20 g or 22) within thenetwork 100.FIG. 7a schematically shows an example of an owner granting permission to the guest to accesssubject device 22 using permissions management infrastructure,FIG. 7b schematically shows an example of an owner granting permission to the guest to accesssubject device 22 usingenvoy device 1, andFIG. 8 schematically shows an example interaction between theguest device 2 andsubject device 22. - As with the
envoy device 1, it will be appreciated that theguest device 2 may be any suitable data processing device e.g. a smartwatch, smartphone, tablet etc. - In the illustrative example of
FIGS. 6 and 7 a, the guest requests permission to accesssubject device 22. - In some examples, the
guest device 2 may request permission from thepermissions management infrastructure 102 directly e.g. via an application running on the guest device 2 (as depicted byfeature 131FIG. 6 ). - Alternatively, in some examples, the
guest device 2, may request permission from thepermissions management infrastructure 102 indirectly via a suitable data processing device such as an owner's envoy device 1 (as depicted byfeatures FIG. 6 ) or a subject device. - On receiving the request from
guest device 2,permissions management infrastructure 102 may request a public key Puk(Guest) from theguest device 2. Alternatively, theguest device 2 may automatically provide the public key Puk(Guest) as part of the request. Theguest device 2 may also provide other device identifiers to the permissions management infrastructure, either automatically or on request e.g. unique device identifier (e.g. IPv6 address) and/or device owner identifiers (‘Owned by GuestX’). - In some examples, the
permissions management infrastructure 102 may comprise adatabase 111, comprising device identifiers associated with data processing devices (e.g. guest devices) which are permitted/prohibited from accessing subject devices. Therefore, thepermissions management infrastructure 102 may check thedatabase 111 as to whether theguest device 2 making the request is permitted to access the subject device for which permission is requested. - In some examples, additionally or alternatively to checking the
database 111, thepermissions management infrastructure 102 may communicate with the owner e.g. viaenvoy device 1 to verify if theguest device 2 should be permitted to access thesubject device 22. - For example, the
permissions management infrastructure 102 may communicate with the owner via a user interface (UI) on theenvoy device 1 and provide an option to the owner to confirm whether or not permission should be granted to theguest device 2. - For example a proposal communication may be communicated to the
envoy device 1 from theIDM 108 and displayed to the owner via the UI, whereby the proposal communication may state: - “Guest device (Owned by GuestX′) requests permission to access
subject device 22—Grant permission ‘Yes’ or ‘No’?” - The owner may then respond by providing an input e.g. via a touch input, corresponding to ‘Yes’ or ‘No’, which is transmitted as a consent status communication to the
permissions management infrastructure 102 e.g. to theIDM 108. - Additionally or alternatively, the owner may also set/limit the permissions for the
guest device 2 in the consent status communication e.g. via an application running on theenvoy device 1. - As illustratively shown in
FIG. 7a , if the owner grants permission to theguest device 2 to access subject device 22 (Step 220), and/or set/limit permissions, thePCE 106 may generate the respective permissions (Step 222), which in the present example comprises an ACL as previously described. - In the present example, the
PCE 106 then communicates the ACL to theIDM 108. TheIDM 108 combines the guest device's public key Puk(Guest) with the ACL to providecertificate 120 and signs thecertificate 120 with a private key Prk(Owner) associated with the owner. The signedcertificate 120 is then transmitted to the guest device 2 (Step 224), either directly (as indicated by feature 131 (FIG. 6 )) or indirectly e.g. via envoy device 1 (as indicated byfeatures 132 and 133 (FIG. 6 )). - As before, the
permissions management infrastructure 102 may be provisioned with the private key (Prk(Owner)), e.g. upon registration of the owner with thepermissions management infrastructure 102 e.g. usingenvoy device 1. - In alternative examples (not shown in
FIG. 7a ), the permissions management infrastructure is not provisioned with the private key Prk(Owner), but, as above, thesubject device 22 may be provided with a public key Puk(PMI) of thepermissions management infrastructure 102, e.g. during the registration process by the owner. Therefore, thepermissions management infrastructure 102, may sign the certificate of 120 with the corresponding private key Prk(PMI). - While in the example illustratively shown in
FIG. 7a the permission management infrastructure generates the permissions, in a further example, the owner may, e.g. using theenvoy device 1, generate the permissions and transmit the permissions directly to theguest device 2, whereby theguest device 2 may then provide the permissions the subject devices. As such it will be seen that the permissions management infrastructure may comprise theenvoy device 1. - Such functionality is illustratively shown in
FIG. 7b whereby the owner may, via an application running on theenvoy device 1 define permissions forguest device 2, whereby the application may automatically generatecertificate 120 comprising ACL locally on theenvoy device 1 and sign the certificate with the private key of the owner Prk(Owner). Theenvoy device 1 may then transmit the signed certificate to theguest device 2. In the present example, as above, theenvoy device 1 may be provisioned with the public key Puk(Guest) of theguest device 2. - Using the functionality illustratively shown in
FIG. 7b , there is no requirement for theenvoy device 1 orguest device 2 to have network connectivity with the permissions management infrastructure to generate permissions, as all permissions may be generated locally on theenvoy device 1 and communicated to theguest device 2 using a suitable communications protocol e.g. BLE, Bluetooth and/or ZigBee. - The
envoy device 1 may also, when network connectivity is available, transmit a description of the permissions granted to theguest device 2 to thepermissions management infrastructure 102 for storage thereat, so thepermissions management infrastructure 102 is aware of the generated permissions and/or theguest device 2. Such a description may comprise the signedcertificate 120. -
FIG. 8 shows an example of theguest device 2, having the signedcertificate 120, requesting access to thesubject device 22 and being authenticated by thesubject device 22. - At
step 230, thesubject device 22 is provided with the public key Puk(Guest) associated with theguest device 2, which is stored in memory circuitry thereon. Provision of Puk(Guest) at thesubject device 22 may occur at any suitable time and may be provided using a suitable communications protocol, by theguest device 2, theenvoy device 1 and/or directly or indirectly from thepermissions management infrastructure 102 e.g. fromIDM 108. - At
step 232, theguest device 2 requests access to thesubject device 22. Atstep 234, thesubject device 22 transmits a nonce to theguest device 2 in order for theguest device 2 to prove its identity. - At
step 236, theguest device 2 signs the nonce with its private key Prk(Guest) which corresponds to public key Puk(Guest) provided to the subject device 22 (Step 230), and transmits the signed nonce andcertificate 120 to thesubject device 22. In some examples the signed nonce may be combined with certificate 120 (as shown inFIG. 8 ). - To verify the identity of the
guest device 2 thesubject device 22 may verify the signed nonce e.g. using Puk(Guest). Thesubject device 22 may then verify the signedcertificate 120 using Puk(Owner) (or Puk(PMI) as appropriate), and, if verified, allow access thereof to the authenticatedguest device 2 as specified in the ACL. (Step 238.) - Furthermore, by providing the public key (Puk(Guest)) of the
guest device 2 in thecertificate 120, it may be possible for thesubject device 22 to further verify that the guest device sending the certificate is the guest device to which the certificate was actually issued by theIDM 108, e.g. by comparing the public key of guest device in thecertificate 102 with the public key provided to the subject device (at step 230). - Using the above described functionality, only guest devices having a certificate signed by an authorized party (e.g. by the owner's
envoy device 1 or the permissions management infrastructure 102) will be authenticated and therefore be provided access to subject devices as specified in the ACL. - Furthermore, using the above described functionality, when permissions are provided to the
guest device 2 frompermissions management infrastructure 102 on the cloud, theguest device 2 would be required to have a network connection to receive the certificate directly from thepermissions management infrastructure 102. However, once the certificate is received, theguest device 2 could provide the certificate to the subject device locally e.g. via BLE, whereby the subject device could authenticate the guest device and implement the ACL. Therefore, there is no requirement for the subject device to be constantly connected to a network. - Alternatively, the guest device may receive the certificate indirectly from the
permissions management infrastructure 102, e.g. via an owner's envoy device using BLE. The guest device could then provide the certificate to the subject device locally e.g. via BLE, whereby the subject device could authenticate the guest device and implement the ACL. Therefore, there is no requirement for the guest device or the subject device to have a constant network connection. - Furthermore, as above blacklists may be sent to the subject devices directly or indirectly. For example, the blacklists may be communicated to the subject device via a guest device which itself is blacklisted. If, for example, the guest device requests access to a subject device, on receiving the request, the PCE may verify the device attributes of the requesting guest device. The PCE may then generate a certificate comprising a blacklist having the public key of the requesting guest device. The IDM may then encrypt the certificate using the public key of the subject device, sign the certificate using the private key of the permissions management infrastructure (or the owner as appropriate) and send the certificate to the guest device. On receiving the certificate, the guest device can present it to the subject device, which decrypts the certificate, verifies the signature and implements the blacklist, thereby denying access to subject device by the guest device. The guest device will not be aware of the blacklist within the certificate as the certificate will be encrypted.
- Using such functionality, it is possible for subject devices to maintain updated blacklists, even if the blacklists are provided to the subject devices by known rogue devices.
- Furthermore, the permissions management infrastructure may push certificates comprising ACLs to the subject devices directly or indirectly e.g. via an owner envoy device or via guest device, whereby the subject devices may then authenticate the guest device and check the permissions in the ACL for each guest device locally. In the case the subject devices receive the updated ACLs directly from the permissions management infrastructure, the subject devices would require occasional network connectivity to receive the updated ACLs, while in the case of receiving the ACLs indirectly, only the device receiving the ACL is required to have network connectivity.
- It will be appreciated that in some examples, the subject devices may authenticate the guest devices and check the permissions granted to the guest devices by communicating directly with the permissions management infrastructure. For such functionality, the subject devices should have network connectivity at the time of authentication.
- Therefore, it will be appreciated that the
permissions management infrastructure 102 may generate permissions based on instructions of an owner, or based on requests from a guest (e.g. using PCE 106), while thepermissions management infrastructure 102 may manage the generated permissions, and implement the permissions on a data processing device (e.g. guest device, subject device) in communication therewith or via a device associated with the owner (e.g. using the IDM 108). - As illustratively shown in the examples at
FIGS. 9 and 10 , and as described below, thepermissions management infrastructure 102 may automatically generate new permissions based on various input data, and further implement the automatically generated permissions on various data processing devices (e.g. subject devices, envoy devices). - The input data may include one or more of the following taken alone or in combination:
-
- a set of rules/policies defined by an owner to set permissions for an associated subject device(s), whereby the rules/policies may be set by the owner dependent on different use cases;
- guest identity, which may be defined in a guest account associated with permissions management infrastructure or provided in real time by the owner via an owner envoy device; and/or
- contextual information which may be derived for example, from device identifiers associated with subject devices, guest devices, owner devices or other resources on a network.
- The owner may create a rule at the
permissions management infrastructure 102, whereby the rule is created by the owner e.g. via an application running on the owner's envoy device, and stored indatabase 111 at thepermissions management infrastructure 102. - As an example, a rule/policy which an owner may use to set permissions is an IF: THAT; THEN THAT rule/policy, whereby as an illustrative example with reference to
FIG. 10a , the rule requires: - IF: permission is granted to a guest device to access a first subject device within a network having a first device identifier for example, a data type identifier=‘high_sensitive_data’ (
e.g. entry sensor 20 c,door lock 20 f, alarm 20 g); - THEN: grant permission to the guest device to access all subject devices on the network having the same data type identifier.
- In the above example, on being granted permission to access the
alarm 20 g, the guest device will also be permitted to access theentry sensor 20 c and door lock 20 f, whereby thePCE 106 will generate the necessary permissions (e.g. as an ACL) and theIDM 108 will communicate corresponding certificates to the guest device to allow it to access the subject devices matching the criteria as before. - As a further example of a rule/policy, as illustratively shown in
FIG. 10b , the owner has one or more subject devices innetwork 100 which are in the same device class, whereby, for example, device class identifier=‘household_appliance/’ (e.g. temperature sensor 20 a,light sensor 20 b,air conditioning unit 20 d,lightbulb 20 e), while the owner has further subject devices in thenetwork 100 which are in a different class, whereby device class identifier=‘security_appliance/’ (e.g. entry sensor 20 c,door lock 20 f,smart alarm 20 g). - Therefore, in the above illustrative example, if a
guest device 2 is permitted to access thetemperature sensor 22, the guest will automatically be permitted to access thetemperature sensor 20 a,light sensor 20 b,air conditioning unit 20 d,lightbulb 20 e as a result of the owner created policy, whereby, for example, thePCE 106 will automatically generate the permissions and theIDM 108 will communicate the corresponding certificate(s) to theguest device 2. However, theguest device 2 will not automatically be permitted to access the entry sensor, door lock and/or smart alarm as those devices comprise a different device class identifier, and the guest will have to request permission to access those subject devices. - As a further example of a rule/policy, the
PCE 106 may be configured to automatically grant permission for aguest device 2 to access all subject devices within a work environment having certain device identifiers (e.g. device class identifier=‘work_device/’) if the owner grants permission to the guest device to enter the work environment e.g. via an entry sensor. - As a further example of a rule/policy, the
PCE 106 may be configured to automatically grant permission for aguest device 2 to access all subject devices having the same device class identifiers (e.g. ‘household_appliance/’) if the owner grants permission to the guest device to access at least one subject device having that device class identifier. - In a further illustrative example of a rule/policy, a lighting system (not shown) comprising a plurality of smart-lights installed in Cambridge city suddenly starts malfunctioning, due to the smart-lights having being compromised by malware such that hackers can control the smart-lights as they wish.
- In general, Cambridge city technicians may have permissions to run local maintenance action on the smart-lights (e.g. to detect malware, identify faults) but not the permissions to install software e.g. to reinstall the operating system (OS) or reflash firmware.
- An emergency rule set up at the permissions management infrastructure by the owner (e.g. the Cambridge City Council IT team) states that in the case of a subject device being compromised, the city technicians will be granted the necessary permissions to re-install the OS and/or reflash memory e.g. to eliminate local malware.
- Therefore, in the present illustrative example, the city technician may indicate that the smart-lights have been compromised (e.g. via an application on the envoy device), and therefore the PCE will automatically generate the permissions to allow all city technicians to install software and transmit the permissions to the technician's envoy device e.g. via the IDM.
- The PCE may also blacklist the hacker and create a blacklist of permissions (e.g. as an ACL) comprising details of the hacker (e.g. the network address of the hacker), which can be sent to all subject devices of the owner, e.g. via the permissions management infrastructure to prevent future access to a subject device by the hacker.
- Furthermore, the permissions management infrastructure may use information relating to guest identity as input data to automatically generate permissions. As an illustrative example, a guest (Guest D) may register with the permissions management infrastructure associated with an owner of subject devices e.g. by creating a guest account therewith via a web application.
- As part of the registration, the guest may provide information relating to the guest identity and identity of any data processing devices associated with the guest to the permissions management infrastructure. Such information may include unique device identifiers and/or public keys of guest devices, which may be stored in database at the permissions management infrastructure.
- The owner may then set the permissions associated with the guest identity and the associated guest devices for the various subject devices of the owner. As above, when the permissions are set by the owner, the PCE will generate permissions for the subject devices permitted to be accessed by the guest e.g. as ACLs comprising the unique device identifiers of the guest's data processing devices allowed to access the subject devices. The IDM will then transmit the ACLs to the subject devices directly or indirectly (e.g. as part of a certificate transmitted to the guest's data processing devices).
- If a guest obtains a new guest device which is not yet permitted to access a subject device, the guest may communicate device identifiers of the new guest device to the permissions management infrastructure (e.g. unique device identifier, public key of the device and device owner identifier=“Device_Owned_by_Guest D)
- On receiving the device identifiers as input data, the
PCE 106 may automatically generate permissions for the new guest device to allow the guest access, through the new guest device, all subject devices which he was previously permitted to access by the owner. - Alternatively, the owner may set a rule/policy which states that any new guest devices belonging to the guest will be provided with the same permissions as the guest's existing devices.
- The PCE may, for example using a machine learning algorithm (e.g. regression analysis), automatically generate permissions for guest devices and/or subject devices based on contextual information which may be derived from communications from subject devices, guest devices, owner devices within a network, or extracted from a database and used as input data.
- For example, the device identifiers of subject devices and/or guest devices may provide contextual information e.g. where the device is located, who owns the device, what type of device does the owner intend to use the device as e.g. household appliance/security appliance. Such device identifiers, may be communicated to the permissions management infrastructure by each of the subject devices directly or indirectly and stored within a database thereat.
- In an illustrative example, the PCE may recognise that an owner repeatedly sets the same permissions for subject devices having identical device identifiers within a certain location. Therefore, the PCE may be configured to automatically generate the same permissions for any new subject devices having the same device identifiers within the same area.
- As an illustrative example, an owner may purchase a temperature sensor subject device, turn it on e.g. within the secure zone of network.
- As described above, when turning the temperature sensor on, the owner would use an owner envoy device to interact with the temperature sensor to, take ownership thereof and discover device identifiers and/or set the device identifiers and transmit the device identifiers to the permissions management infrastructure. In the present example the device identifiers may include (device class identifier=sensor), (device location identifier=secure_zone).
- The PCE would analyse the device identifiers provided by the envoy device and automatically generate permissions using the device identifiers and any contextual information as input data.
- In a further illustrative example, as generally depicted in
FIG. 10b , a new subject device is atemperature sensor 22 and is located within the secure zone of thenetwork 100, comprising othersubject devices - Therefore, because the owner has previously added other subject devices having identical device class identifiers in the secure zone which publish operational data to a website which can be accessed by the owner's family & friends, the
PCE 106 will automatically generate permissions (e.g. as an ACL) for thenew temperature sensor 22 to allow it to publish operational data to the website which can be accessed by the owner's family and friends. - The
IDM 108 may be used to manage implementation of the permissions on the new subject device, including obtaining owner consent to apply any automatically created permission by sending a proposal communication to owner e.g. via the owner's envoy, and managing the distribution of the permission to the subject device based on whether consent is received from the owner e.g. as a consent status communication. As before, theIDM 108 may upload permission to the newsubject device 22 directly or indirectly e.g. via the owner's envoy device. - As a further illustrative example of using contextual information to generate permissions, a technician ‘Mr Y’ from ‘Company A’ installs a subject device comprising a smoke alarm in a clean room having a security level=1, within a maximum security building. The technician, takes ownership of the smoke alarm via an envoy device and sets the device identifiers accordingly, and communicates the device identifiers to the PCE.
- As the subject device is a smoke alarm located in a clean room having an associated security level of 1, within a maximum security building, the PCE will use the device identifiers set by the technician as input data and automatically generate a permission based on the context derived from the device identifiers.
- Therefore, an example permission may be that the smoke alarm may only be locally accessed by a specific category of technician, for example by technicians being able to demonstrate
Clean room 1 technician status e.g. by having a certificate signed with a Private key corresponding to such technicians, or, for example using an envoy device having a device identifier listed within an ACL on the smoke alarm. A further permission may be that the smoke alarm is to be accessible to certain external parties, e.g. by SCADA1 system. - The IDM may then push the permission to ‘MR Y's’ envoy device which, in turn, pushes the permission to the smoke alarm detector for implementation thereon.
- An owner may also update permissions for subject devices/guest devices at the permissions management infrastructure.
- Therefore, for example, if a guest device has existing permissions to access a subject device, and the guest device enters the proximity of the subject device, then the guest device may be configured to automatically check with the permissions management infrastructure as to whether there are any updates to the existing permissions, and the IDM can push any updated permissions to the guest device or to the subject device.
- As an illustrative example, if a guest device is permitted to access features on a subject device e.g. for N days, then after N days pass, the guest device may automatically check with the permissions management infrastructure if there are any updated permissions for the guest device e.g. to extend the permissions.
- If there are updated permissions e.g. if the owner has agreed to extend the permissions or if the
PCE 106 has automatically created permissions, theIDM 108 can automatically push the updated permissions to the guest device. Such updated permissions may be set by the owner, and stored within adatabase 111. - Furthermore, an owner may modify the permissions associated with certain subject devices, e.g. the owner may change the location that a subject device is to publish data to and/or may prohibit certain guest devices accessing the subject devices. The modified permissions may then be transmitted to the
permissions management infrastructure 102. - On receiving the updated permissions, the PCE may generate updated ACLs having the updated permissions and the IDM will manage the distribution accordingly. If the IDM cannot communicate the updated permissions to the subject device directly or indirectly, e.g. due to lack of connectivity, the permissions may be stored in the database until connectivity becomes available.
- Therefore, if an owner enters the proximity of a subject device with an
envoy device 1, the envoy device may check with the permissions management infrastructure as to whether there are any updated permissions for the subject device, and the IDM may push the updated permissions in the database to the envoy device, which in turn will push the updated permissions to the subject device e.g. via BLE. - Therefore, it will be appreciated that the subject devices are not required to be connected to the cloud to receive updated permissions, but can receive permissions via various data processing devices in proximity thereto (e.g. guest devices and/or owner envoy devices etc.).
- As before after taking ownership of a subject device, the owner may transmit a description of ownership to the permissions management infrastructure, whereby the description of ownership may comprise the device identifiers of the subject device.
- In further examples, the owner may, for example using an application running on the owner envoy device, create groups into which subject devices may be classified, whereby each of the groups may have associated rules at the permissions management infrastructure as defined by the owner. As above the PCE may automatically generate access permissions depending on the defined rules, and the IDM may distribute the permissions accordingly.
- For example, the owner may create a ‘private’ group, and further create a rule at the permissions management infrastructure whereby subject devices classified as being within the ‘Private’ group are to be inaccessible to data processing devices other than those belonging to the owner.
- As a further example, the owner may define a ‘public’ group, and further create a rule whereby subject devices classified as being within the ‘Public’ group are accessible by any data processing device whatsoever.
- It will be appreciated that the owner may define further groups and define any associated rules dependant on the requirements of the particular owner. For example, such groups may include, a ‘Friends’ group, a ‘Family’ group, an ‘Employees of Company X’ group, ‘Temporary Employees group’ etc.
- In order to determine which data processing devices are classified as falling within any particular group, the permissions management infrastructure may communicate with a remote resource such as a remote directory service e.g. an address book on the owner's mobile device, a server database, and/or a web application to identify such data processing devices e.g. by device identifiers listed in the directory (e.g. a device owner identifier).
- Using such functionality the permissions management infrastructure may readily generate permissions for multiple subject devices and transmit the permissions to multiple guest devices, whereby, for example, the PCE may be used to generate the permissions, and the IDM used to distribute the permissions to the appropriate devices.
- As an illustrative example of such functionality,
FIG. 11a shows an example of an owner taking ownership of a newsubject device 22, which in the present example is depicted as amusic player 22. As above the ownership procedure may be undertaken by transmitting the owner's public key Puk(Owner) to themusic player 22 from the owner'senvoy device 1. - In the present example, the owner defines a ‘Friends’ group at the permissions management infrastructure e.g. via an application on the
envoy device 1, and further defines a rule that any data processing devices belonging to a friend e.g. via an envoy device owned by a friend, hereinafter “friend device”, is permitted to access themusic player 22. - In order to determine which devices are classified as a friend device, the
permissions management infrastructure 102 communicates withremote directory service 130, which in the present example is a web application comprising a list of all the owner's friends and their associatedfriend devices 2 a-2 n. - The
PCE 106 may automatically generate permissions for all friend devices, and theIDM 108 may automatically communicate the permissions to each of thefriend device 2 a-2 n. - Using such functionality, all the owner's friends may via their
respective friend device 2 a-2 n access themusic player 22 as described above, and, for example control which music is played by themusic player 22, and listen to the tunes played on themusic player 22. - Using such functionality, it is also possible to blacklist one or more devices within a group. In an illustrative example,
FIG. 11b schematically illustrates an example of an owner blacklisting afriend device 2 b. - In
FIG. 11b ,friend device 2 b is blacklisted by the owner, whereby the friend is removed from the friends list. As such the owner notifies thepermissions management infrastructure 102, e.g. via an application on theenvoy device 1. - In an alternative example, the permissions management infrastructure may periodically check with the
remote directory service 130 as to whether there are any updates to the group. - The
PCE 106 may then notify themusic player 22 of the change in permissions, e.g. by pushing an updated ACL comprising the blacklisted device identifier (e.g. the public key of thefriend device 2 b) to themusic player 22. Therefore, any request to access the music player byfriend device 2 b will be denied. - Using such functionality, permissions to specific devices within user defined groups may be easily revoked, while without revoking permissions for all devices within the group.
- While the PCE and IDM are shown to be discrete elements within the permissions management infrastructure above, it will be appreciated that the PCE and IDM may be implemented using any suitable configuration.
- For example the PCE and IDM may be provided as part of the same processing engine running on a single server. Alternatively, the PCE and IDM may be implemented as different data processing engines running on the same server or the PCE and IDM may be implemented as processing engines on remote servers in communication with each other.
- It will be appreciated also that while the figures above generally depict the subject devices as being within a local network in a home environment, the subject devices are not required to be located in a home or work environment, and may be distributed in any network configuration as required by the owner e.g. throughout a building, a business park, a town, a country, a continent or worldwide. Furthermore, there is no requirement for the subject devices to be within the same network.
- It will be appreciated that an owner is taken to be a party authorized to access the subject devices and may be a single party or an owner may comprise multiple parties. For example, an owner may be a homeowner having the subject devices in his/her home. Alternatively, the owner may be a team of employees of a business which legally owns the subject devices, whereby, for example, the team of employees interact with the subject devices on behalf of the legal owner.
- Although illustrative embodiments have been described in detail herein with reference to the accompanying drawings, it is to be understood that the embodiments are not limited to those precise embodiments, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope of the embodiments as defined by the appended claims.
- According to a first aspect there is provided a method of creating, at a permissions management resource, access permissions relating to a subject device for at least one data processing device, the method comprising: obtaining, at the permissions management resource, input data; generating, at the permissions management resource, at least one permission relating to accessing the subject device in response to the input data; transmitting, from the permissions management resource to the subject device or the at least one processing device, a communication comprising the at least one permission.
- The input data may comprise permissions set by an authorized party and/or the input data may comprise at least one of: a rule/policy defined by an authorized party; a device attribute of the at least one data processing device; a device attribute of the subject device, and/or contextual information.
- The input data may comprise classification data relating to the subject device, wherein the classification data may relate to a group within which the subject device is classified by the authorized party.
- The method may further comprise: generating, at the permissions management resource, a communication comprising a request for at least one device attribute associated with the group; transmitting the communication comprising the request to a remote directory service; receiving, at the permissions management resource from the remote directory service, the device attribute relating associated with the group.
- Generating at least one permission in response to the input data may comprise: automatically generating the at least one permission at the permissions management resource; transmitting, from the permissions management resource, a permission proposal communication to an authorized party, wherein the permission proposal communication may comprises data relating to the automatically created at least one permission; receiving at the permissions management resource, a consent status communication in response to the permission proposal communication and transmitting the communication comprising the at least one permission to the subject device is based on the consent status communication.
- Transmitting the communication comprising the at least one permission may comprise transmitting the communication directly or indirectly to the subject device or the at least one data processing device.
- The at least one permission may comprise a certificate and/or an access control list, wherein the certificate may further comprise a credential associated with the at least one data processing device, wherein the credential associated with the data processing device may comprise a first cryptographic key, wherein the first cryptographic key may be associated with the at least one data processing device, wherein the first cryptographic key may comprise a public key of the at least one data processing device.
- The certificate may further comprise a credential associated with an authorized party, wherein the credential associated with the authorized party may comprise a second cryptographic key, wherein the second cryptographic key may be associated with the authorized party, wherein the second cryptographic key may comprise a private key of the authorized party.
- The method further may further comprise: generating, at the permissions management resource, a blacklist of permissions; transmitting, from the permissions management resource, a communication comprising the blacklist of permissions to the subject device.
- In a further aspect there is provided a permissions management resource for creating permissions relating to a subject device, the permissions management resource comprising: a permission creation engine configured to generate permissions based on input data; and an identity management engine configured to manage the permissions generated at the permission creation engine and to communicate the permissions to the subject device or at least one data processing device directly or indirectly.
- The input data may be set by an authorized party, wherein the input data may comprise at least one of: a rule/policy defined by an authorized party; a device attribute of at least one data processing device; a device attribute of the subject device, and/or contextual information, wherein the permission creation engine may be configured to automatically generate the permissions based on the input data.
- The method may comprise: generating, at the data processing device, a request communication comprising a request to access the subject device; transmitting, from the data processing device to a permissions management resource, the request communication; receiving, at the data processing device, from the permissions management resource, a permissions communication comprising at least one permission relating to the subject device in response to the request communication.
- Transmitting the request communication may comprise, transmitting the request communication directly or indirectly to the permissions management resource.
- Receiving the permissions communication may comprise, receiving the permissions communication directly or indirectly from the permissions management resource.
- The method may further comprise: transmitting, from the data processing device to the subject device, the at least one permission.
- The at least one permission may comprise a certificate, wherein the certificate may comprise a credential associated with a resource authorized by the subject device and/or wherein the certificate may comprise a credential associated with the data processing device and/or wherein the certificate may comprise an access control list.
- The method may further comprise: receiving, at the data processing device from the permissions management resource, a blacklist of permissions and transmitting, from the data processing device to the subject device, the at least one permission.
- In a further aspect there is provided a method of claiming ownership of a subject device, the method comprising: receiving, at the subject device, a communication comprising a credential from a resource remote therefrom; storing, within storage circuitry at the subject device, the credential; and associating the credential with an owner of the subject device.
- The remote resource may comprise a data processing device associated with the owner and/or the remote resource may comprise a permissions management resource.
- The credential may comprise a cryptographic key.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/448,718 US20190372981A1 (en) | 2015-01-21 | 2019-06-21 | Methods and resources for creating permissions |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB1501027.5A GB2534557B (en) | 2015-01-21 | 2015-01-21 | Methods and resources for creating permissions |
GB1501027.5 | 2015-01-21 | ||
US15/001,750 US10333938B2 (en) | 2015-01-21 | 2016-01-20 | Methods and resources for creating permissions |
US16/448,718 US20190372981A1 (en) | 2015-01-21 | 2019-06-21 | Methods and resources for creating permissions |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/001,750 Continuation US10333938B2 (en) | 2015-01-21 | 2016-01-20 | Methods and resources for creating permissions |
Publications (1)
Publication Number | Publication Date |
---|---|
US20190372981A1 true US20190372981A1 (en) | 2019-12-05 |
Family
ID=52630917
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/001,750 Expired - Fee Related US10333938B2 (en) | 2015-01-21 | 2016-01-20 | Methods and resources for creating permissions |
US16/448,718 Abandoned US20190372981A1 (en) | 2015-01-21 | 2019-06-21 | Methods and resources for creating permissions |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/001,750 Expired - Fee Related US10333938B2 (en) | 2015-01-21 | 2016-01-20 | Methods and resources for creating permissions |
Country Status (2)
Country | Link |
---|---|
US (2) | US10333938B2 (en) |
GB (1) | GB2534557B (en) |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9264237B2 (en) * | 2011-06-15 | 2016-02-16 | Microsoft Technology Licensing, Llc | Verifying requests for access to a service provider using an authentication component |
US10320613B1 (en) * | 2015-08-11 | 2019-06-11 | Cisco Technology, Inc. | Configuring contextually aware IoT policies |
US10129229B1 (en) * | 2016-08-15 | 2018-11-13 | Wickr Inc. | Peer validation |
US10382203B1 (en) * | 2016-11-22 | 2019-08-13 | Amazon Technologies, Inc. | Associating applications with Internet-of-things (IoT) devices using three-way handshake |
KR102661645B1 (en) | 2016-12-15 | 2024-05-02 | 삼성전자주식회사 | Electric device and method for control thereof |
US10911224B1 (en) * | 2018-03-21 | 2021-02-02 | Amazon Technologies, Inc. | Secure network-enabled lock |
US11868917B1 (en) | 2018-03-21 | 2024-01-09 | Amazon Technologies, Inc. | Sensor-based door lock confidence |
JP6713612B1 (en) * | 2019-01-22 | 2020-06-24 | 株式会社ビットキー | Usage management system, management device, usage control device, usage management method, and computer-readable program |
JP6792229B1 (en) * | 2019-08-28 | 2020-11-25 | 株式会社ビットキー | Usage management system, management device, usage control device, usage management method, and program |
US11310235B1 (en) * | 2021-08-04 | 2022-04-19 | Netfay Inc. | Internet of things system based on security orientation and group sharing |
Family Cites Families (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6601171B1 (en) * | 1999-02-18 | 2003-07-29 | Novell, Inc. | Deputization in a distributed computing system |
US7444414B2 (en) * | 2002-07-10 | 2008-10-28 | Hewlett-Packard Development Company, L.P. | Secure resource access in a distributed environment |
US20040083386A1 (en) * | 2002-10-28 | 2004-04-29 | Bertrand Marquet | Non-repudiable distributed security policy synchronization |
US7493296B2 (en) * | 2006-05-31 | 2009-02-17 | International Business Machines Corporation | Method and system for classifying information |
US20080104393A1 (en) * | 2006-09-28 | 2008-05-01 | Microsoft Corporation | Cloud-based access control list |
US8468579B2 (en) * | 2007-06-15 | 2013-06-18 | Microsoft Corporation | Transformation of sequential access control lists utilizing certificates |
US8381204B2 (en) * | 2008-04-30 | 2013-02-19 | International Business Machines Corporation | Compiler driven mechanism for registration and deregistration of memory pages |
US8140853B2 (en) * | 2008-07-01 | 2012-03-20 | International Business Machines Corporation | Mutually excluded security managers |
CN103621048B (en) * | 2011-07-11 | 2016-08-17 | 甲骨文国际公司 | Utilize at least one in multicast group and packet transaction agency to support the System and method for of flooding mechanism in middleware machine environment |
CA2747444C (en) * | 2011-07-26 | 2017-10-10 | Rem Enterprises Inc. | Inlet air extractor for a particulate loader and transfer apparatus |
US8856530B2 (en) * | 2011-09-21 | 2014-10-07 | Onyx Privacy, Inc. | Data storage incorporating cryptographically enhanced data protection |
US8954733B2 (en) * | 2012-03-23 | 2015-02-10 | International Business Machines Corporation | Embedded extrinsic source for digital certificate validation |
US9131266B2 (en) * | 2012-08-10 | 2015-09-08 | Qualcomm Incorporated | Ad-hoc media presentation based upon dynamic discovery of media output devices that are proximate to one or more users |
US20140244997A1 (en) * | 2013-02-25 | 2014-08-28 | Qualcomm Incorporated | Emergency mode for iot devices |
US10257665B2 (en) * | 2013-02-25 | 2019-04-09 | Qualcomm Incorporated | Analytics engines for IoT devices |
WO2014138530A2 (en) * | 2013-03-08 | 2014-09-12 | Siemens Healthcare Diagnostics Inc. | Surface markings for an optically guided device |
US9794782B2 (en) * | 2014-10-15 | 2017-10-17 | Belkin International Inc. | Simplification of attaching devices to secured wireless networks |
DE102014213443A1 (en) * | 2014-07-10 | 2016-01-28 | Siemens Aktiengesellschaft | Method for improving shim presets of a magnetic resonance device |
GB2531247B (en) | 2014-10-07 | 2021-10-06 | Arm Ip Ltd | Method, hardware and digital certificate for authentication of connected devices |
US9729383B2 (en) * | 2014-10-15 | 2017-08-08 | Ayla Networks, Inc. | Flexible rules engine for managing connected consumer devices |
US9800619B2 (en) * | 2014-10-15 | 2017-10-24 | Ayla Networks, Inc. | Registration framework for connected consumer devices |
US9094407B1 (en) * | 2014-11-21 | 2015-07-28 | Citrix Systems, Inc. | Security and rights management in a machine-to-machine messaging system |
US9690361B2 (en) * | 2014-12-24 | 2017-06-27 | Intel Corporation | Low-power context-aware control for analog frontend |
-
2015
- 2015-01-21 GB GB1501027.5A patent/GB2534557B/en active Active
-
2016
- 2016-01-20 US US15/001,750 patent/US10333938B2/en not_active Expired - Fee Related
-
2019
- 2019-06-21 US US16/448,718 patent/US20190372981A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
GB2534557A (en) | 2016-08-03 |
GB201501027D0 (en) | 2015-03-04 |
GB2534557B (en) | 2022-03-09 |
US10333938B2 (en) | 2019-06-25 |
US20160212137A1 (en) | 2016-07-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20190372981A1 (en) | Methods and resources for creating permissions | |
US11522865B2 (en) | Automated IoT device configuration using user profile | |
US10951630B2 (en) | Registry apparatus, agent device, application providing apparatus and corresponding methods | |
US11387978B2 (en) | Systems and methods for securing access rights to resources using cryptography and the blockchain | |
US10911424B2 (en) | Registry apparatus, agent device, application providing apparatus and corresponding methods | |
US12010248B2 (en) | Systems and methods for providing authentication to a plurality of devices | |
KR102117584B1 (en) | Local device authentication | |
US11683183B2 (en) | Autonomously generated portable accounts | |
CN108702360B (en) | Digital asset protection policy using dynamic network attributes | |
US11637834B2 (en) | Dynamic passcodes in association with a wireless access point | |
TWI666903B (en) | Uniform communication protocols for communication between controllers and accessories | |
US9867051B2 (en) | System and method of verifying integrity of software | |
US9374361B2 (en) | Cross-native application authentication application | |
KR102168392B1 (en) | Registry apparatus, agent device, application providing apparatus and corresponding methods | |
US20170264613A1 (en) | Communication mechanism for data processing devices | |
JP2017520865A (en) | Use mobile devices to operate with limited concentration on other mobile devices | |
CN109891852B (en) | Apparatus and method for providing a user-configured trust domain | |
Zhang et al. | Sovereign: Self-contained smart home with data-centric network and security | |
US20180367308A1 (en) | User authentication in a dead drop network domain | |
KR102377045B1 (en) | SYSTEMS AND METHODS FOR AUTHENTICATING IoT DEVICE THROUGH CLOUD USING HARDWARE SECURITY MODULE | |
WO2018207174A1 (en) | Method and system for sharing a network enabled entity | |
US20230020855A1 (en) | Network access tokens for accessories | |
WO2018045475A1 (en) | Secure indirect access provisioning of off-line unpowered devices by centralized authority |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: ARM LIMITED, UNITED KINGDOM Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:POTTIER, REMY;VINCENT, HUGO JOHN MARTIN;PHILLIPS, AMYAS EDWARD WYKES;AND OTHERS;SIGNING DATES FROM 20160113 TO 20160210;REEL/FRAME:049552/0450 Owner name: ARM IP LIMITED, UNITED KINGDOM Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:POTTIER, REMY;VINCENT, HUGO JOHN MARTIN;PHILLIPS, AMYAS EDWARD WYKES;AND OTHERS;SIGNING DATES FROM 20160113 TO 20160210;REEL/FRAME:049552/0450 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |