EP4162662A1

EP4162662A1 - System and method for authenticating a device on a network

Info

Publication number: EP4162662A1
Application number: EP21731844.3A
Authority: EP
Inventors: Gysbert Johannes Jacobs
Original assignee: IotNxt BV
Current assignee: IotNxt BV
Priority date: 2020-06-03
Filing date: 2021-06-03
Publication date: 2023-04-12
Also published as: WO2021245599A1

Abstract

Methods and systems are provided for authenticating a device on a network. A method (204) includes receiving a message from the device (130), the message cryptographically signed with a device private key. The message (600) includes a device identifier (500) that is computed (402), using the device private key, from at least one descriptor of a hardware component associated with the device, a counter value (604) associated with the device identifier; and a service key request (608). The method further includes verifying (416) the message signature using a device public key. The received counter value is verified (412) to be greater than a previously received counter value associated with the device identifier. A service key is generated (418) and linked to the device identifier. The service key is sent (424) to the device to enable it to communicate through secure network connections.

Description

SYSTEM AND METHOD FOR AUTHENTICATING A DEVICE ON A NETWORK

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from South African provisional patent application number 2020/03301 filed on 3 June 2020, which is incorporated by reference herein.

FIELD OF THE INVENTION

The invention disclosed herein relates to methods and systems for authenticating a device and particularly for securing communication and access within a network and between devices in such a network. It finds particular use, although not exclusive, in Internet of Things (loT) networks.

BACKGROUND TO THE INVENTION

The “Internet of Things’’ or ΊoT” is a term relating to a network of billions of physical electronic devices that are connected to the internet. Historically, mostly computing devices with high computing power and connectivity were considered to be “connected’’ to and thus accessible via the internet. However, the “things” in “Internet of Things” include devices previously generally considered to be stand-alone and often unintelligent devices. As such, loT devices may include devices as simple as a residential light switch or a pressure sensor on an industrial boiler.

At a low level, the application of loT technology includes the remote controlling and monitoring of every connected device, called “end-nodes”. However, the possibilities that this enables have far- reaching implications for industry. The incoming data from end-nodes may, for example, be directed to one or more central processing locations where the data can be processed, analysed, and used in decision-making. Appropriate action may be taken based on this incoming data by remotely controlling the end-nodes as required.

The incoming data from the end-nodes may further help to improve the insights and efficiency in business processes when these devices are genuine, authorised and not tampered with. The impact of these connected end-node devices in an loT environment, and the severity of the impact of a misbehaving end-node device, varies depending on the use cases. Considering many of these use cases are in mission critical environment and a rogue device can disrupt the entire business process and result in massive liabilities to an organisation. An exemplary application of loT technology in the mining industry may serve as an illustration of the impact that misbehaving end-nodes may have. Mining vehicles may be fitted with loT end- node sensors to measure oil temperature, contamination, tire pressure, vibration, engine speed, brake pressure, etc. and transmit the sensor data remotely to a server. The server may monitor this data in real-time and recommend maintenance schedules. Should it detect a potentially dangerous operating condition, the server could immediately send alerts to maintenance crews to attend to the problem before breakdown and/or injury takes place. Should an end-node produce such alerts erroneously, it may lead to extremely costly unnecessary down-times. Worse yet, if the end-node does not produce alerts when required, it could lead to human injury or loss of life.

In another scenario, a sensor (of an end-node) may detect human presence in an environment before operating equipment. A malfunctioning end-node may similarly lead to human injury or loss of life.

It is therefore clear that maintaining the integrity of the loT network through the stringent scrutinising of end-nodes is desirable, such as device enrolment, authentication and decommissioning. The devices that may form part of the loT network are diverse and may range from a device as simple as a temperature sensor to an “intelligent” device with integrated security features and powerful computing capabilities. It may therefore prove challenging to perform device administration (such as the enrolment, authentication and decommissioning mentioned above) in a standardised manner.

Accordingly, the Applicant considers there to be scope for improvement.

The preceding discussion of the background to the invention is intended only to facilitate an understanding of the present invention. It should be appreciated that the discussion is not an acknowledgment or admission that any of the material referred to was part of the common general knowledge in the art as at the priority date of the application.

SUMMARY OF THE INVENTION

In accordance with the invention there is provided a method for authenticating a device on a network comprising: receiving a message from the device, the message cryptographically signed with a device private key and including: a device identifier that is computed, using the device private key, from at least one descriptor of a hardware component associated with the device; a counter value associated with the device identifier; and a service key request; verifying the message signature using a device public key; verifying whether the received counter value is greater than a previously received counter value associated with the device identifier; generating a service key and linking the service key to the device identifier; and sending the service key to the device to enable it to communicate through secure network connections.

The method may include storing the received device identifier, generating a globally unique identifier (GUID) and linking the stored device identifier with the generated GUID. The method may include sending the generated GUID to the device with the service key. The method may include receiving a further message from the device that includes a device identifier and the GUID and comparing the received device identifier with the stored device identifier linked to the GUID. If the received device identifier does not match the stored device identifier, the message may be rejected.

The method may include receiving the device identifier and the counter value associated with the device identifier from the device in response to one or more of the effluxion of a configured time period, the network device being powered or reset, or a change in a configuration of the device. The method may include verifying the received device identifier against the stored device identifier associated with the device, verifying whether the received counter value is greater than the previously received counter value associated with the device identifier; and if the verification fails, rejecting the message.

The device identifier may include a cryptographic derivative of the device private key. The cryptographic derivative may be a hash-based message authenticated code (HMAC) computed using the device private key. The service key may be part of a cryptographic key pair that enables the device to communicate through a cryptographic protocol that provides end-to-end secure network connections. The cryptographic protocol may be a transport layer security (TLS) protocol.

The hardware descriptor may be one or more of a media access control (MAC) address, an International Mobile Equipment Identity (IMEI) number, a memory size, an amount of network interfaces, a central processor unit (CPU) serial number, a hard drive serial number, and a Trusted Platform Module (TPM) serial number. The message may further include one or more of an application programming interface (API) key, a cryptographic salt value, a bitmap value indicating the types of attributes included in the message. The message may further include attributes of sensors connected to the network device.

In one embodiment, the device is an Internet of Things edge gateway.

In another embodiment, the device is in data communication with an Internet of Things edge gateway, and the received message may include one or more of descriptors of the port and/or communication interface through which the device communicates with the edge gateway, and a descriptor of the functionality of the device.

In a further embodiment, the device may be a logical device associated with an edge gateway comprising a sensor connected to the edge gateway through a wired connection and for the one or more hardware descriptor included in the computation of the device identifier to be a hardware descriptor of the edge gateway to which it is connected.

The method may include receiving a device identifier change request including the GUID, the device identifier, a hardware change descriptor indicating whether the identifier change request relates to a hardware removal or hardware addition, and a new device identifier computed subsequent to the corresponding hardware change on the device. The method may include linking the new device identifier to the GUID.

The device identifier change request may be for an edge gateway and for the request may include new device identifiers of logical devices associated with the edge gateway computed subsequent to the corresponding hardware change on the edge gateway. The method may include linking the new device identifiers of the logical devices to their respective GUID’s.

In accordance with a further aspect of the invention there is provided a system for authenticating a device on a network, the system including a server having a memory for storing computer- readable program code and a processor for executing the computer-readable program code, the server comprising: a receiver component arranged to receive a message from the device, the message cryptographically signed with a device private key and including: a device identifier that is computed, using the device private key, from at least one descriptor of a hardware component associated with the device; a counter value associated with the device identifier; and a service key request; a signature verification component arranged to verify the message signature using a device public key; a counter verification component for verifying whether the received counter value is greater than a previously received counter value associated with the device identifier; a key generator component for generating a service key and linking the service key to the device identifier; and a sender component for sending the service key to the device to enable it to communicate through secure network connections.

The server may include a storage component arranged to store the received device identifier, to generate a globally unique identifier (GUID) and to link the stored device identifier with the generated GUID. The server may include a comparator component arranged to compare a GUID received in a data message from the device that includes a device identifier with the stored device identifier linked to the GUID.

The server may include a cryptography component arranged to derive a cryptographic derivative of the device private key. The cryptography component may include a hash computing component for computing a hash-based message authenticated code (HMAC) using the device private key.

The server may include a secure protocol component arranged to enable secure end-to-end network connections using the service key. The secure protocol component may include a TLC component arranged to secure end-to-end network connections with transport layer security (TLS).

In accordance with a further aspect of the invention there is provided a computer program product for authenticating a device on a network, the computer program product comprising a computer- readable medium having stored computer-readable program code for performing the steps of: receiving a message from the device, the message cryptographically signed with a device private key and including: a device identifier that is computed, using the device private key, from at least one descriptor of a hardware component associated with the device; a counter value associated with the device identifier; and a service key request; verifying the message signature using a device public key; verifying whether the received counter value is greater than a previously received counter value associated with the device identifier; generating a service key and linking the service key to the device identifier; and sending the service key to the device to enable it to communicate through secure network connections.

Further features provide for the computer-readable medium to be a non-transitory computer- readable medium and for the computer-readable program code to be executable by a processing circuit.

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

Figure 1 is a schematic of a system for authenticating a network device;

Figure 2 is a flow diagram of a typical life cycle of a network device;

Figure 3 is a swim lane flow diagram of device commissioning step in further detail;

Figure 4 is a swim lane flow diagram of device ownership step in further detail;

Figure 5 is a block diagram of a data structure on which a device identifier is computed;

Figure 6 is a block diagram of a data structure of a data message that may be sent by a network device;

Figure 7 is a swim lane flow diagram of steps performed to change a device identifier; Figure 8 is a block diagram showing functional units of an identity server; and

Figure 9 illustrates an example of a computing device in which various aspects of the disclosure may be implemented.

DETAILED DESCRIPTION WITH REFERENCE TO THE DRAWINGS

Methods and systems are described below for authenticating a device on a network. In a method, a message is received, for example at an identity sever on the network, from the network device that is to be authenticated. The message has been cryptographically signed by the network device using a private cryptographic key stored on and known only by the relevant device. To enable the device to be authenticated by the identity server or another entity on the network, the message includes a device identifier that is unique to the device and which serves as a sort of device biometric, or “Device DNA”, which includes or is computed using parameter values associated with the device. This device identifier is computed, cryptographically, using the device private key and may take the form of a cryptographic hash that is derived using the device’s private key. This inextricably links the device identifier to the device private key which, as mentioned above, is known only to the relevant device and is never sent to another party or device.

The device identifier or “Device DNA” is cryptographically computed on a data packet that is compiled using various parameters associated with the device. The data packet includes at least one descriptor of a hardware component of the device, such as a hard driver serial number, Trusted Platform Module (TPM) serial number, a memory size of the device, and the like. A counter value is also included in the message that is incremented by the device each time a message containing the device identifier is sent from the relevant device to frustrate replay attacks from miscreants attempting to imitate the device. The identity server or other entity that receives a message from the network device that includes its device identifier is therefore configured to confirm that the counter is greater than the counter of the preceding message received from the same device.

The received message further includes a service key request. This service key request is generated by the device as part of an enrolment process and forms part of a cryptographic key pair. Once the service key is signed by Public Ke Infrastructure (PKI) on the network, which may be performed by the identity server, the service key request becomes the public of a service key pair which will allow the device to communicate on the network through secure communication protocols, such as Transport Layer Security (TLS) protocols. As mentioned above the message received from the device is cryptographically signed using the device private key. The identity server is, at the enrolment stage, in possession of the public device key associated with the device’s private key and can therefore verify the signature of the message using the device’s public key.

When the message is verified in this manner, the identity server signs the service key request, producing a public service key with which the device is to communicate through secure network connections. The identity server then links this generated service key to the device. This may be done by generating a Globally Unique Identifier (GUID) for the device and storing the service key in a database accessible by the identity server indexed against this generated GUID. The GUID may be returned to the device for storage thereon and the device may include it in subsequent messages sent to the identity server.

Such subsequent messages to the identity server may be for periodic or event driven re authentication of the network device, for example when the device identifier attributes change, after the effluxion of a certain time period, after network configuration changes, or when the device restarts.

These methods and systems may therefore enable authentication by using a unique device identifier or “Device DNA” which uniquely identifies a hardware (or software) device by means of which the authenticity of every enrolled device on a network, such as an Internet of Things (loT) network can be verified. This is analogous to biometric information associated to a user which uniquely identifies a person, and which can then be used to authenticate the person in a computer system in a more secured fashion compared to passcode-based authentication.

Figure 1 is a schematic representation of a system (100) for authenticating a device on a network. The system (100) includes a server that facilitates the secure administration of the identities of network users, hereinafter referred to as the identity server (110).

The system (100) further includes a secure Internet of Things (loT) platform (120) that facilitates the access, administration, and management of network devices that forms part of an loT network. The loT platform (120) provides a user interface through which an administrator may view data relating to loT devices enrolled on the loT network, for management of such loT devices, and facilitates communication to and from the loT devices. The loT platform (120) furthermore facilitates the administration of authorised users that are authorised to access loT devices, their access privileges, and the particular loT devices which they are authorised to access. The system (100) includes an loT edge gateway (130), which facilitates communication between the loT platform (120) and a number of loT end-nodes that are connected to the edge gateway (130). In terms of loT technology, an loT edge gateway is a physical device or software that serves as a connection point between loT end-nodes (sensors, actuators, and the like) and a network such as a local network or the Internet. The edge gateway (130) communicates with the loT platform (120) through a computer network (140). Communication between the edge gateway (130) and the loT platform (120) is performed through a secure communication protocol via the network (140) which, in the present embodiment, is secured through Transport Layer Security (TLS) connections (142).

The edge gateway (130) is a purpose-built device, that is to say that its intended use is that of an loT gateway device. This is to distinguish this edge gateway (130) from other general-purpose computing devices that, through software configuration, may perform the same or similar functions as an loT edge gateway, an example of which is discussed further below. The edge gateway (130) includes a variety of connection options to loT end-nodes. In the present example it includes a number of Ethernet connections for communication with TCP/IP-enabled devices. It also includes wireless communication capabilities to enable the edge gateway (130) to communicate with Wi-Fi-enabled devices through secure TCP/IP connections and with Bluetooth- enabled devices that are paired therewith. It also includes connections to enable the edge gateway (130) to communicate with simpler devices through hard-wired connections, such as through a one-wire communication bus, a serial peripheral interface (SPI) bus, and the like.

Figure 1 shows a number of exemplary end-nodes connected to the edge gateway (130), through various communication interfaces and protocols. An IP camera (132) is shown that is connected to the edge gateway (130) through an Ethernet cable (133). In the present embodiment, the IP camera (132) does not have the capabilities of establishing secure connections and therefore communicates with the edge gateway (130) through unsecured TCP/IP protocols.

The edge gateway is further connected to a credit-card sized computer (134), such as a Raspberry PI™ that is also connected through an Ethernet cable (135). Flowever, the communication between the edge gateway (130) and the credit-card sized computer (134) is through a secure TLS connection. The credit-card sized computer (134) is itself in communication with a number of devices, such as access panels, lights, and sensors.

The edge gateway is also in communication with a digital temperature sensor (136) through a hard-wired connection. In the present embodiment, the digital temperature sensor (136) is a DS18B20 digital temperature sensor and is communicated with through an l²C bus (137). The system (100) also includes another credit card sized computer (150) which is, through software, configured to be an edge gateway in the loT network and thus communicates with the loT platform (120) through the network (140) with secure TLS connections (142). This is therefore an example of a general-purpose computing device that is configured through software to be an edge gateway, as opposed to a purpose-built edge gateway.

The system (100), and more particularly the loT end nodes therein, therefore includes a variety of devices having varying architectures, varying degrees of computing power, intelligence, communication interfaces and protocols, and security features. The identity server (110) is configured to facilitate a standardised method of authentication for this variety of loT end-nodes as is explained in further detail below.

Figure 2 shows a flow diagram of a typical life cycle (200) of an loT network device, such as the loT edge gateway (130). When a network device is in a factory reset state (either after initial manufacturing or subsequent resetting), the device needs to be commissioned (202) to enable it to be authenticated by the identity server (110) and/or the loT platform (120). As part of this commissioning (202) process, a unique device identifier will be compiled for the relevant device as explained in further detail below with reference to Figure 3.

The methods for authenticating a device disclose herein allow devices to communicate through the network (140) and with the loT platform (120) if owned by an authenticated user. As part of the device ownership (204) step, the authorised user associated with the particular device may be recorded. The device ownership (204) step may differ between enterprise device scenarios and consumer device scenarios. For enterprise scenarios the device ownership step (204) may be combined with the device commissioning (202) step as an enterprise administrator would be assigned to manage the devices. In the consumer scenario the device ownership (204) step may be performed either at the time of device activation, or at the time of purchase by a store operator.

In the enterprise device scenario, in which the devices are administered by an administrator, the administrator may allocate the ownership of new devices to other users. Users may then be notified and will be able to activate and manage these devices after logging onto the loT platform (120). In the consumer (self-managed) scenario users may log onto the loT platform (120) and view a list of unclaimed devices available for ownership. This ownership aspect assigns a certain responsibility of the device to the owner.

Once a user takes ownership of a device, the owner can activate (206) the device. Once the device is activated its corresponding edge gateways may be notified and the relevant devices allowed to communicate on the network (140) and with the loT platform (120). Once a device is activated, end-points associated with the device may be available for end-point management from the loT platform (120).

The device activity (208) stage represents the standard mode of a device after it has been successfully activated.

Device decommissioning (210) occurs when the device is replaced or the terms of services for the particular device have are ended, for example, and allows for a graceful termination and removal of the relevant device. If may also allow differentiation between device theft and device termination.

Figure 3 is a swim lane flow diagram showing the device commissioning (202) step shown in Figure 2 in further detail. The different lanes in the diagram indicates steps executed at the relevant device, i.e. the identity server (110) or the network device. For the purposes of illustrating the steps, the edge gateway (130) will be used as the network device hereinafter. It is assumed that the edge gateway (130) would be pre-configured with certain configurations, such as any required application programming interface (API) keys, network settings, and setting of devices connected thereto, such as the IP camera (132) and the temperature sensor (136) in this scenario. These configuration settings may be set by an end-user or systems administrator beforehand.

The authentication methods disclosed herein makes use of cryptographic key pairs and, as an initial step, the edge gateway generates (302) a private key associated with the device (hereinafter also referred to as the “device private key” or “DK_pri”) and an accompanying certificate signing request (hereinafter also referred to as “DK_csr”). The device private key and the certificate signing request is then sent to the identity server (110).

The identity server (110) receives the key and request and revokes (304) any existing certificates for the particular device. This may be required when the edge gateway (130) is reset and therefore needs to be re-commissioned afresh. The identity server (110) then, acting as Public Key Infrastructure (PKI), signs the certificate signing request (DK_csr) and generates a public key associated with the device (hereinafter also referred to as the “device public key” or “DK_pub”). The device public key (DK_pub) is then returned (306) to the edge gateway (130).

The edge gateway (130) generates (308) a cryptographic salt value for subsequent use in creating the unique device identifier explained further below and stores the generated salt and the device key pair (DKjori, DK_pub). It bears mentioning that the key pair generation happens in such a way that the device private key never leaves the edge gateway (130). This implies that the DK_pri is not known to any party, except the device that generated DK pri. The edge gateway (130) also initialises a device counter value to a zero value and stores the device counter value. The salt value is not to be changed for the relevant device unless again being re-commissioned afresh. The device counter value is to be used to frustrate replay attacks in subsequent device authentication as described below.

At this stage, i.e. after the commissioning step (202), the network device (presently the edge gateway (130)) is equipped to be enrolled on the network through an authentication process between it and the identity server (110) during which the device’s identifier is verified, stored, and the device is issued with network access keys. This is performed during the device ownership step (204) explained below.

Figure 4 shows a swim lane flow diagram of the device ownership (204) step shown in Figure 2 in greater detail. As a sub-step of the device ownership (204) step, the unique device identifier mentioned above will be computed (402) and the properties of the device identifier is firstly explained.

As mentioned above, due to the variety of different devices on the loT network, the information that may be used to identify the particular device also varies. For example, the unique information available on edge gateways and IP-enabled devices differ substantially. Some devices may have multiple network adapters with identifiers such as media access control (MAC) addresses, while other network devices may have GSM modems with identifiers such as an International Mobile Equipment Identity (IMEI) number. Some devices may have hard drives with parameters such as a serial number, manufacturer identifier, and the like while other devices may operate from SD cards with card identification registers containing similar parameters. Other hardware identifiers that may be used include an available amount of memory of the device, an amount of available network interfaces on the device, a processor serial number, and a trusted platform module (TPM) serial number, to name a few examples.

The authentication methods disclosed herein include generating a unique device identifier despite such device differences and therefore provides a normalised authentication scheme.

The computation of the device identifier or “Device DNA” includes a derivative of a token or key that is only available on the network device in question which, in the present embodiment, is the device key pair (DK_pub, DK_pri) generated during the device commissioning (202) step and stored on the device. The public key (DK_pub) should be signed for use by a system-wide Certificate Authority (CA) meaning that the key pair is authorised to be used within the network and that the authorisation can be verified cryptographically. Including a derivative (hash or fingerprint) of the device key may ensure that no attacker can forge the device identifier even if every unique hardware identifier on the relevant device was manipulated.

To enable the edge gateway (130) or other network device to generate a unique device identifier, the device key pair (DK_pri, DKjoub) should already have been generated and stored on the device; at least one hardware identifier should be available; and the device’s cryptographic salt value should be available for use. The device identifier is computed using the device private key and is therefore a derivative of the device private key (DKjori). This inextricably links the device identifier to its device private key. The device identifier, in this embodiment, is a hash-based message authentication code (HMAC) and is computed on a data structure that includes at least one descriptor of a hardware component of the network device. A number of other attributes may be included in the data structure, and Figure 5 shows an example of a data structure from which the HMAC may be computed using the device private key to form the device identifier (500).

The device identifier (500) is an HMAC (501 ) computed on a data structure that includes an API key (502) of the functionality that the device may want to access through the network (140). An attribute bitmap (504) is included with each bit in the bitmap being assigned a particular type of attribute. For example, a MAC address may be assigned to bit position 0 and a bitwise OR operation may be performed on this attributes bitmap (504) with the hexadecimal value 0x01 to determine whether the data structure includes a MAC address attribute. The data structure furthermore includes a cryptographic salt value (506) to frustrate rainbow table attacks attempting to recreate the HMAC value (and thus the device identifier (500)). The data structure further includes a value indicating the total number of identifiers (508) included in the data structure. For each identifier of this total, an attribute type and attribute value are included in the data structure. For example, to continue the example of a MAC address, the attribute type of the first identifier (510) is included as attribute type 0x01 (512), and its value as the MAC address 22:00:4E:1 E:90:11 (514).

The data structure further includes, if applicable, a total number of sensors (520) attached to the network device. For each sensor of this total, a port or interface (524) descriptor is included as well as a descriptor of the sensor type (526) as shown for the first sensor (522) in Figure 5. In the present example, the edge gateway (130) has a digital thermometer (136) connected to its l²C bus and the port/interface value (524) and sensor type (526) may indicate this. This data structure may then be serialised into a flattened data structure and the HMAC (501) computed thereon using the device private key (DKjori) to produce the device identifier (500).

A number of device types and the associated computation of the device identifier are envisaged and are discussed below. Device Identifier (“Device DNA”1 of Edge Gateway

The edge gateway (130) is a network-connected device with various communication interfaces. The edge gateway (130) facilitates the use of hardware that uses a wide variety of communication protocols. The edge gateway (130), therefore, acts as a gateway for connected devices by supplying them with required services needed to connect to a secure loT platform (120). An example of such a device is the digital thermometer (136) connected to the edge gateway (130) through its l²C bus (137).

An edge gateway (130) can communicate with devices through Wi-Fi, Bluetooth, Ethernet, a serial port and a variety of other interfaces to ultimately connect devices to the secure loT platform (120). An edge gateway (130) may further possess cryptographic capabilities (hardware or software) and may also possess a Trusted Platform Module (TPM) or hardware cryptographic modules

The device identifier (500) (“Device DNA”) of the edge gateway (130) is generated by combining the unique hardware characteristics with a derivative of the edge gateway (130) device private key (DK_pri) to create a unique identifier.

Device Identifier (“Device DNA”^') of hardwired devices

The edge gateway (130) allows access to one or more devices as mentioned above with reference to the example of the digital thermometer (136). This makes it possible for such devices to connect to the secure loT infrastructure via the edge gateway (130). However, it bears mention that such devices cannot connect to the secure loT platform (120) by themselves as they do not possess “intelligence”, processing abilities, network access architecture, etc. and therefore needs to utilise the capabilities of the edge gateway (130) to facilitate such connections. There is therefore an explicit dependency between such a device (for example the digital thermometer (136)) and the edge gateway (130).

Such dependent devices are therefore considered logical devices in that their device identifiers or “Device DNA” computation will require the use of the edge gateway’s cryptographic keys to access the network (140) and the secure loT platform (120). Expiry or revocation of the edge gateway’s (130) cryptographic keys will therefore not only disconnect the edge gateway (130, but also all other devices (connected through it) to the secure loT network (such as the digital thermometer (136) and IP camera (132)). These devices can consequently not function as stand alone devices. Since hardwired devices are so intertwined with the edge gateway (130) it is connected to, the computation of a hardwired device’s device identifier is to include parameters of the edge gateway (130) as well as its own parameters, such as a hardware component serial number of the hardwired device, or a port or interface descriptor through which it connects to the edge gateway (130) for example. Therefore, the device identifier for a hardwired device may be computed similarly as that of the edge gateway (130) but with the data structure on which it is computed to include a port or interface (virtual or physical) through which the device connects to the edge gateway (130) and a device type.

Device Identifier (“Device DNA”) of IP-enabled Devices without Security Capabilities An edge gateway (130) can connect IP-enabled devices to a network (140) and secure loT platform (120) that cannot do so on its own. Certain IP-enabled devices do not have cryptographic and security capabilities. The IP camera (132) connected to the edge gateway (130) may be such an IP-enabled device. The manner in which a device identifier of such a device is to be computed is therefore similar as that of a hardwired device as described before, with the device parameters included in its computation including descriptors relating to the port or interface to which the device connects with the edge gateway (130) and a device type.

Device Identifier (“Device DNA”) of IP-enabled Devices with Security Capabilities An edge gateway (130) can also connect IP-enabled devices to a network (140) and secure loT platform (120) that do have cryptographic and security capabilities. Such IP-enabled devices may therefore communicate with the edge gateway (130) through secure TCP/IP connections, such as TLS. This would imply that the device has cryptographic certificates associated therewith that allow it to communicate via these secure connections. The computation of such devices may therefore include a certificate common name of these cryptographic certificates, however it may also furthermore include descriptors relating to the port or interface to which the device connects with the edge gateway (130) and a device type.

Other IP-enabled devices, for example a credit-card size computer (150) such as the Raspberry Pi™, enable the loading of software thereon that facilitate the connection with the network (140) and secure loT platform (120). Such devices may furthermore be configured through software to effectively become edge gateways. The device descriptors of such devices may therefore be computed similarly to that of a purpose-built edge gateway (130).

Device Identifier (“Device DNA’”) of Devices with Hardware-based Security Capabilities Devices with hardware-based security features (such as a TPM) and that support secure communication such as TLS can connect to the edge gateway (130) using secure connections. Similarly as before, the device identifier computation of such devices may include a certificate common name.

However, the computation may furthermore include a unique identifier of the hardware-based security components of the device. The purpose of a TPM is to store private asymmetric keys as well as symmetric keys. Key management is the essence of cryptography, and without proper key management, the cryptographic systems are meaningless. These keys are never available for access outside the TPM, and it is not possible to read the keys from the TPM in any way. The use of the TPM makes it possible to manage keys in a way that guarantees that the keys are safe, even if an attacker obtained network access or physical access to the device.

Again, the computation of the device identifier may also furthermore include descriptors relating to the port or interface to which the device connects with the edge gateway (130) and a device type.

Referring back to Figure 4, having computed (402) its device identifier (500), the edge gateway (130) then generates (404) a private service key (hereinafter also referred to as “SK_pri”) and a service key signature request (hereinafter also referred to as “SK_csr”), the purpose of which will be explained further below.

The edge gateway (130) then compiles (406) a data message, an exemplary structure of which is shown in Figure 6. The data message (600) includes a version number (602) that indicates to a recipient what the format of the data message is. Should the format of the data message change in future, the recipient will be able to differentiate the changed format from the version number (602). The data message (600) further includes the device identifier (500) and the above- mentioned counter value (604). Since this message is compiled as part of a commissioning process, and will be the first from this device, the counter value will be zero.

The data message (600) further includes the edge gateway (130) device public key (DK pub) (606) and the certificate signing request (SK_csr) (608) corresponding to the key generated in step (404). The recipient of the message is requested to sign the certificate signing request (SK_csr), thereby producing the corresponding public service key (hereinafter also referred to as “SK_pub”). Without the matching service key pair (SKjori, SKjoub) the edge gateway (130) will not be able to access any TLS-secured network devices. Network access, and access to the loT platform (120) are therefore cryptographically controlled and conditional. What is more, network access can be revoked by revoking the service public key SK_pub. The edge gateway (130) then signs (406) the data message (600) using its device private key (DK pri), which appends a signature (610) to the data message (600). The edge gateway (130) then sends (408) the data message to the identity server (110), increments the counter value and stores it for future use.

Upon receiving the data message from the edge gateway (130), the identity server (110) recognises the data message as including a service key certificate signing request (SK_csr) and therefore revokes (410) any service keys or certificates that may currently be associated with the edge gateway (130). The identity server (110) then verifies (412) whether the received counter value is greater than a counter value in the previously received message from the edge gateway (130) or, more particularly, linked to the device identifier (500) in the data message. However, in the present scenario, this is the very first message that the edge gateway (130) has sent the identity server (110) and the counter therefore has a zero value.

The identity server (110) then verifies (414) the received device public key (DK_pub) to ensure that the certificate originated from the PKI which, in the present scenario, is also the identity server (110). The verification (414) includes verifying whether it has been revoked previously and whether the certificate is still active according to a validity period that may be specified in the certificate.

Having verified the integrity of the device public key (DK_pub), the identity server (110) verifies (416) the signature of the received data message using the device public key (DK_pub). It will be recalled that the data message had been signed with the corresponding device private key (DK_pri) in step (406). Once all the afore-mentioned verifications have been performed, the service key certificate signing request (SK_csr) included in the received data message is signed (418) by the identity server, thereby creating a service public key (SKjoub).

The identity server (110) then links (420) the created service public key (SK_pub) to the device identifier (500) of the edge gateway (130). The identity server (110) then generates (422) a GUID associated with the edge gateway (130). The generated GUID and the created service public key (SKjoub) is then sent (424) to the edge gateway (130) which then stores (426) the received items.

During the device activity stage (208) stage, the edge gateway (130) (continuing with it as an exemplary network device) may be required to reconfirm its identity to the identity server (110). This may be required after the effluxion of a configured time period (periodically), when the edge gateway (130) is powered or reset, or if a configuration of the edge gateway is changed. The edge gateway (130) will then again send a data message, similar in structure as shown in Figure 6, however without the service key certificate signature request since it is already in possession of a service key pair. The data message will therefore include at least the device identifier (500), the counter value (604), the device public key DKjoub (606) and a signature (610).

The version number (602) may also be included to indicate the data message structure to the recipient; and may also include the GUID generated for the relevant device and against which the identity server (110) linked the device identifier (500). The identity server (130) may then verify the received device identifier (500) against a stored device identifier associated with the device. However, the identity server (110) will firstly verify whether the received counter value is greater than a previously received counter value associated with the device identifier failing which it will reject the message and log the event. Alternatively, the identity server (110) will accept the re verification and store the counter value associated with the relevant device identifier for future comparison.

It bears mention that, during the device commissioning step (202), and thus also when the device is re-commissioned, the device key pair (DK_pri, DK_pub) will change and, necessarily, the device identifier as well. The device will again initialise its counter value to zero since it had not previously communicated with the identity server (110) with this new device identifier. A manual counter reset is therefore not required.

An attacker could potentially capture a device identifier payload on the network or obtain the device identifier through other means. The attacker could potentially construct a new payload, increment the counter, and sign the payload using their own device private key. It is envisaged that, if the attacker’s device private key is valid and the specified device identifier is allowed on the system, an attacker could obtain access in such a manner. To ensure that such an attack would not succeed, the subject of the device public key should be linked to the device identifier when the device identifier is linked by the identity server (110) to the created service public key (SKjoub) to the device identifier. This would imply that all data messages that include the device identifier would have to originate from a device public key having the same subject as the device public key that was used when linking the device identifier. Any attacker that captures the device identifier afterwards would not simply be able to forge and sign the data message using the captured device identifier since the attacker would also need access to the device key pair for such an attack to succeed, provided that the PKI (identity server (110) in this case) does not allow duplicate subjects.

There are a number of notable properties associated with the device identifier that deserve further mention. The device identifier will change when any critical hardware changes are made to the device, since the device identifier uses the current hardware identifiers to compile the device identifier. The API key used to obtain network access is also included in the computation of the device identifier and an API license key change would require that the network device is recommissioned. The device identifier remains constant for as long as no hardware changes are made to the device. When a device is recommissioned, for whatever reason, the device identifier will change since the device will acquire a new device private key, which is used to compute the device identifier. It is possible to host one or more (logical) devices on an edge gateway and each device will have its own device identifier. It is also possible to have two or more devices connected to the device identifier that logically work together as a cohesive unit. In such configurations the devices will share a collective device identifier.

Furthermore, the device identifier features the number of notable security properties. It is not possible to use any device identifier that has been captured, with a network sniffer for example, due to the cryptographic signature and counter requirements discussed above. Replay attacks are therefore not possible. Rainbow table attacks are made infeasible using salt values as part of the device identifier computation. The inclusion of aderivate of the device private key in the device identifier cryptographically binds the device identifier to the device private key and if the device private key remains protected no attacker would be able to forge the device identifier. For this reason, it may be advantageous to use a trusted platform module (TPN) to secure the device private key (DK_pri). It would be possible to stop an loT device from registering for service keys (for accessing TLS communications) by revoking the device public key (DK_pub) or by blacklisting the device’s device identifier. A device would need to be recommissioned when its device public key (DK_pub) has been revoked, the device identifier blacklisted or if the device identifier should change.

Device Identifier Changes

It is further envisaged that a network device, such as the edge gateway (130), may undergo hardware changes that affect its device identifier during its lifetime. For example, the device may include a serial number of its hard drive in the computation, its device identifier and, if the hard drive fails and requires replacement, the device identifier will necessarily change. It would therefore be advantageous to implement a method by which certain device identifier changes may be authorised and recorded without requiring an entire device recommissioning. The recordal of the changed device identifier may occur through linking the GUID previously linked to the prior device identifier to the new device identifier. Requiring human intervention to authenticate this change may be impractical for a large-scale deployment.

A device identifier change should only ever be allowed if the underlying reason for the change is allowed, e.g. the replacement of a particular hardware component. The type of changes that are allowable by default may be configured as a device change policy at the identity server (110). The policy can be system-wide or device specific and may instruct the identity server (110) on the actions that should be performed when hardware change requests are received. Actions prescribed by the policy may include, for example, accept change; reject change; or escalate to administrator for approval. The prescribed actions may be based on the type of hardware changes requested.

It would be advantageous to allow a device identifier change in which the change permission is requested from the identity server (130) before actual changes are made to prevent lengthy wait times during which the device would not be able to communicate on the network (140) or with the loT platform (120). To change device hardware a user or administrator needs to capture the specific changes that are needed to the edge gateway (130) and submit the changes to the identity server (110). These changes may be submitted via the edge gateway (130) or indirectly via a portal of the loT platform (120) which, in turn, may instruct the edge gateway (130) to submit the required information to the identity server (110).

Figure 7 shows a flow diagram of a step (700) of changing the device identifier associated with a device, the edge gateway (130) in this example. The edge gateway (130) creates (702) a device identifier change request, which includes the current device identifier (500), a change type indicator (which represents, for example, adding, moving or changing a hardware component), the device identifiers of all (logical) devices attached to the edge gateway that will be influenced (for example the digital thermometer (136)), its device public key (DKjoub) and a counter value.

The change request packet is then signed (704) with the device's private key (DK_pri) and sent to the identity server (130). The edge gateway (130) then increments (706) and stores the counter value, which is for prevention of replay attacks as discussed above.

The identity server (130) verifies (708) the signature of the received request using the device public key (DK_pub) included in the packet. The device identifier is then verified (710) to ensure that it is enrolled and activated; and verifies (712) whether the received counter value received is greater than previously received from a device with this device identifier, failing which the request is rejected and the incident logged.

The requested device identifier change may be verified according to an implemented device change policy stored at the identity server (110). Depending on such change policy consideration, the identity server (110) may: immediatly approve the change request; immediately reject the change request; or mark the change request as pending (in which case administrator intervention may be required). In the case of a pending approval response, the edge gateway (130) will need to periodically poll the identity server (130) to determine whether the request has been approved or rejected by the administrator.

If the request is approved, the identity server will compile (714) a response message including: a change identifier, an encrypted change key (encrypted with the received device public key DKjoub), an approval validity time period, and the device identifiers of all affected devices that were received as part of the request from the edge gateway (130).

The encrypted change key is a symmetric key that is to be used by the edge gateway in a subsequent step. The change key may only be used once and is preferably re-generated for each change request. The change key is encrypted with the edge gateway (130) device public key (DK pub) to ensure that only it will be able to decrypt the change key. The device identifiers are included in the response to indicate to the edge router (130) what the relevant devices’ device identifier were before the change had been approved to provide for scenarios where the hardware had already been changed. In such a scenario a device identifier computation would produce the new identifier and the edge router (130) and may not be configured to compute the previous identifiers.

The response is then signed (714) using a device private key of the identity server (130) so that the recipient may verify the sender as indeed being the identity server. The response is then sent (714) to the edge gateway (130), and the identity server (110) stores (716) the change identifier, change key and validity period.

After receiving the response from the identity server (110), the edge gateway (130) verifies (718) the signature of the response to confirm its authenticity using a device public key of the identity server (110) and, if verified, stores the response. The edge gateway (130) then notifies (720) the administrator that the request has been accepted. The edge gateway (130) may thereafter either detect that the hardware changes had been effected, or may be notified of the change by the administrator (via the loT platform (120) for example).

The edge gateway (130) then re-calculates (722) its device identifier as well as the device identifiers of all other affected (logical) devices (i.e. those devices connect to and dependent on it). The edge gateway (130) then compiles (724) a data message including: the previous device identifiers, the new device identifiers, and the change identifier. The edge gateway (130) then computes (726) an HMAC of the data message using the decrypted change key and attaches the computed HMAC to the data message. The data message is then sent (728) to the identity server (110). The identity server (130) then retrieves (730) the change key and validity period linked to the change identifier that were stored in step (716). If it is verified (730) that the data message is received within the validity period, the identity server (130) computes an HMAC on the received data message using the retrieved change key and verifies (730) whether it matches the HMAC attached to the received data message. This indicates that the change was authorised by the identity server (130) as only an authorised response would contain a change key that would be able to generate the matching HMAC.

The identity server (130) then verifies (732) whether the received old device identifiers are those linked to the change identifier. If the verification is successful, the identity server (130) updates (734) the link between the GUID associated with the edge router (130) to link to the new device identifier(s). All changes are logged to provide traceability.

The edge gateway (130) may then be notified that the operation was completed successfully which may, in turn, inform the administrator thereof. The edge gateway (130) may thereafter perform the standard procedures to gain access to the network (140) and loT platform (120).

Various components may be provided for implementing the method steps described above. Figure 8 is a block diagram which illustrates exemplary components which may be provided by an identity server (110) in a system for authenticating a network device.

The identity server (110) may include a processor (802) for executing the functions of components described below, which may be provided by hardware or by software units executing on the identity server. The software units may be stored in a memory component (804) and instructions may be provided to the processor (802) to carry out the functionality of the described components. In some cases, for example in a cloud computing implementation, software units arranged to manage and/or process data on behalf of the identity server may be provided remotely.

The identity server (110) includes a receiver component (806) arranged to receive a message from a network device, such as an edge gateway (130). The message is cryptographically signed with a device private key and includes a device identifier that is computed, using the device private key, from at least one descriptor of a hardware component associated with the device; a counter value associated with the device identifier; and a service key request.

The identity server (110) further includes a signature verification component (808) arranged to verify the message signature using a device public key and a counter verification component (810) for verifying whether the received counter value is greater than a previously received counter value associated with the device identifier, if any. A first message associated with a particular device identifier may omit this check since there would be no previous counter value to make a comparison with.

The identity server (110) includes a key generator component (812) for generating a service key and for linking the service key to the device identifier. It further includes a sender component (814) for sending the service key to the device to enable it to communicate through secure network connections.

The identity server (110) further includes a storage component (816) that is arranged to store the received device identifier, to generate a globally unique identifier (GUID) and to link the stored device identifier with the generated GUID. It includes a comparator component (818) that is arranged to compare a GUID received in a data message from the device (that also includes a device identifier) with the stored device identifier linked to the GUID and to reject the message if there is a mismatch.

The identity server (110) includes a cryptography component (820) that is arranged to derive a cryptographic derivative of the device private key. The signature verification component (808) and the key generator component (812) are sub-components of the cryptography component (820). The cryptography component (820) includes a hash computing component (822) as a further sub component that is arranged to compute a hash-based message authenticated code (HMAC) using the device private key.

The identity server (110) further includes a secure protocol component (824) that is arranged to enable secure end-to-end network connections using the service key. It has a TLS component (826) as a sub-component that enables such secure end-to-end network connections with transport layer security (TLS).

The methods and systems disclosed herein therefore enable the authentication of network devices despite the variety of hardware configurations and architectures that network devices may have. The application in loT networks is particularly envisaged, due to the variety of devices that may be connected thereto.

Figure 9 illustrates an example of a computing device (900) in which various aspects of the disclosure may be implemented. The computing device (900) may be embodied as any form of data processing device including a personal computing device (e.g. laptop or desktop computer), a server computer (which may be self-contained, physically distributed over a number of locations), a client computer, or a communication device, such as a mobile phone (e.g. cellular telephone), satellite phone, tablet computer, personal digital assistant or the like. Different embodiments of the computing device may dictate the inclusion or exclusion of various components or subsystems described below.

The computing device (900) may be suitable for storing and executing computer program code. The various participants and elements in the previously described system diagrams may use any suitable number of subsystems or components of the computing device (XX00) to facilitate the functions described herein. The computing device (900) may include subsystems or components interconnected via a communication infrastructure (905) (for example, a communications bus, a network, etc.). The computing device (900) may include one or more processors (910) and at least one memory component in the form of computer-readable media. The one or more processors (910) may include one or more of: CPUs, graphical processing units (GPUs), microprocessors, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs) and the like. In some configurations, a number of processors may be provided and may be arranged to carry out calculations simultaneously. In some implementations various subsystems or components of the computing device (900) may be distributed over a number of physical locations (e.g. in a distributed, cluster or cloud-based computing configuration) and appropriate software units may be arranged to manage and/or process data on behalf of remote devices.

The memory components may include system memory (915), which may include read only memory (ROM) and random access memory (RAM). A basic input/output system (BIOS) may be stored in ROM. System software may be stored in the system memory (915) including operating system software. The memory components may also include secondary memory (920). The secondary memory (920) may include a fixed disk (921 ), such as a hard disk drive, and, optionally, one or more storage interfaces (922) for interfacing with storage components (923), such as removable storage components (e.g. magnetic tape, optical disk, flash memory drive, external hard drive, removable memory chip, etc.), network attached storage components (e.g. NAS drives), remote storage components (e.g. cloud-based storage) or the like.

The computing device (900) may include an external communications interface (930) for operation of the computing device (900) in a networked environment enabling transfer of data between multiple computing devices (900) and/or the Internet. Data transferred via the external communications interface (930) may be in the form of signals, which may be electronic, electromagnetic, optical, radio, or other types of signal. The external communications interface (930) may enable communication of data between the computing device (900) and other computing devices including servers and external storage facilities. Web services may be accessible by and/or from the computing device (900) via the communications interface (930). The external communications interface (930) may be configured for connection to wireless communication channels (e.g., a cellular telephone network, wireless local area network (e.g. using Wi-Fi™), satellite-phone network, Satellite Internet Network, etc.) and may include an associated wireless transfer element, such as an antenna and associated circuity.

The computer-readable media in the form of the various memory components may provide storage of computer-executable instructions, data structures, program modules, software units and other data. A computer program product may be provided by a computer-readable medium having stored computer-readable program code executable by the central processor (910). A computer program product may be provided by a non-transient computer-readable medium, or may be provided via a signal or other transient means via the communications interface (930).

Interconnection via the communication infrastructure (905) allows the one or more processors (910) to communicate with each subsystem or component and to control the execution of instructions from the memory components, as well as the exchange of information between subsystems or components. Peripherals (such as printers, scanners, cameras, or the like) and input/output (I/O) devices (such as a mouse, touchpad, keyboard, microphone, touch-sensitive display, input buttons, speakers and the like) may couple to or be integrally formed with the computing device (900) either directly or via an I/O controller (935). One or more displays (945) (which may be touch-sensitive displays) may be coupled to or integrally formed with the computing device (900) via a display (945) or video adapter (940).

The foregoing description has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Persons skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above disclosure.

Any of the steps, operations, components or processes described herein may be performed or implemented with one or more hardware or software units, alone or in combination with other devices. In one embodiment, a software unit is implemented with a computer program product comprising a non-transient computer-readable medium containing computer program code, which can be executed by a processor for performing any or all of the steps, operations, or processes described. Software units or functions described in this application may be implemented as computer program code using any suitable computer language such as, for example, Java™, C++, or Perl™ using, for example, conventional or object-oriented techniques. The computer program code may be stored as a series of instructions, or commands on a non-transitory computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive, or an optical medium such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

Flowchart illustrations and block diagrams of methods, systems, and computer program products according to embodiments are used herein. Each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, may provide functions which may be implemented by computer readable program instructions. In some alternative implementations, the functions identified by the blocks may take place in a different order to that shown in the flowchart illustrations.

Some portions of this description describe the embodiments of the invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. The described operations may be embodied in software, firmware, hardware, or any combinations thereof.

The language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based hereon. Accordingly, the disclosure of the embodiments of the invention is intended to be illustrative, but not limiting, of the scope of the invention.

Finally, throughout the specification and claims unless the contents requires otherwise the word ‘comprise’ or variations such as ‘comprises’ or ‘comprising’ will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

Claims

CLAIMS:

1 . A method for authenticating a device on a network comprising: receiving a message (600) from the device (130), the message cryptographically signed with a device private key and including: a device identifier (500) that is computed (402), using the device private key, from at least one descriptor of a hardware component associated with the device; a counter value (604) associated with the device identifier; and a service key request (608); verifying (416) the message signature (610) using a device public key; verifying (412) whether the received counter value (604) is greater than a previously received counter value associated with the device identifier; generating (418) a service key and linking (420) the service key to the device identifier; and sending (424) the service key to the device to enable it to communicate through secure network connections.

2. The method as claimed in claim 1 including storing the received device identifier, generating (422) a globally unique identifier (GUID) and linking the stored device identifier with the generated GUID; and sending (424) the generated GUID to the device with the service key.

3. The method as claimed in claim 2 including receiving a further message from the device that includes a device identifier and the GUID and comparing the received device identifier with the stored device identifier linked to the GUID; and, if the received device identifier does not match the stored device identifier, rejecting the message.

4. The method as claimed in claim 3 including receiving the device identifier and the counter value associated with the device identifier from the device in response to one or more of the effluxion of a configured time period, the network device being powered or reset, or a change in a configuration of the device.

5. The method as claimed in any one of the previous claims including verifying the received device identifier against the stored device identifier associated with the device, verifying whether the received counter value is greater than the previously received counter value associated with the device identifier; and if the verification fails, rejecting the message.

6. The method as claimed in any one of the previous claims wherein the device identifier includes a cryptographic derivative of the device private key.

7. The method as claimed in claim 6 wherein the cryptographic derivative is a hash-based message authenticated code (HMAC) computed using the device private key.

8. The method as claimed in any one of the previous claims wherein the service key is part of a cryptographic key pair that enables the device to communicate through a cryptographic protocol that provides end-to-end secure network connections.

9. The method as claimed in claim 8 wherein the cryptographic protocol is a transport layer security (TLS) protocol.

10. The method as claimed in any one of the previous claims wherein the hardware descriptor is one or more of a media access control (MAC) address, an International Mobile Equipment Identity (IM El) number, a memory size, an amount of network interfaces, a central processor unit (CPU) serial number, a hard drive serial number, and a Trusted Platform Module (TPM) serial number.

11 . The method as claimed in any one of the previous claims wherein the message further includes one or more of an application programming interface (API) key, a cryptographic salt value, a bitmap value indicating the types of attributes included in the message, and attributes of sensors connected to the network device.

12. The method as claimed in any one of the previous claims wherein the device is an Internet of Things edge gateway.

13. The method as claimed in any one of claims 1 to 11 wherein the device is in data communication with an Internet of Things edge gateway, and wherein the received message includes one or more of descriptors of the port and/or communication interface through which the device communicates with the edge gateway, and a descriptor of the functionality of the device.

14. The method as claimed in any one of claims 1 to 11 wherein the device is a logical device associated with an edge gateway comprising a sensor connected to the edge gateway through a wired connection and for the one or more hardware descriptor included in the computation of the device identifier to be a hardware descriptor of the edge gateway to which it is connected.

15. The method (700) as claimed in any one of claims 2 to 14 including receiving a device identifier change request (704) including the GUID, the device identifier, a hardware change descriptor indicating whether the identifier change request relates to a hardware removal or hardware addition, and a new device identifier computed subsequent to the corresponding hardware change on the device; and linking (734) the new device identifier to the GUID.

16. The method as claimed in claim 15 wherein the device identifier change request is for an edge gateway and wherein the request includes new device identifiers of logical devices associated with the edge gateway computed subsequent to the corresponding hardware change on the edge gateway; and linking the new device identifiers of the logical devices to their respective GUID’s.

17. A system for authenticating a device on a network, the system including a server (110) having a memory (804) for storing computer-readable program code and a processor (802) for executing the computer-readable program code, the server comprising: a receiver component (806) arranged to receive a message from the device, the message (600) cryptographically signed with a device private key and including: a device identifier (500) that is computed, using the device private key, from at least one descriptor of a hardware component associated with the device; a counter value (604) associated with the device identifier; and a service key request (608); a signature verification component (808) arranged to verify the message signature (610) using a device public key (606); a counter verification component (810) for verifying whether the received counter value is greater than a previously received counter value associated with the device identifier; a key generator component (812) for generating a service key and linking the service key to the device identifier; and a sender component (814) for sending the service key to the device to enable it to communicate through secure network connections.

18. The system as claimed in claim 17 wherein the server (110) includes a storage component (816) arranged to store the received device identifier, to generate a globally unique identifier (GUID) and to link the stored device identifier with the generated GUID; a comparator component (818) arranged to compare a GUID received in a data message from the device that includes a device identifier with the stored device identifier linked to the GUID; and a cryptography component (820) arranged to derive a cryptographic derivative of the device private key.

19. The system as claimed in claim 18 wherein the cryptography component (820) includes a hash computing component (822) for computing a hash-based message authenticated code (HMAC) using the device private key.

20. The system as claimed in any one of claims 17 to 19 including a secure protocol component (824) arranged to enable secure end-to-end network connections using the service key.

21. The system as claimed in claim 20 wherein the secure protocol component includes a TLC component arranged to secure end-to-end network connections with transport layer security (TLS).

22. A computer program product for authenticating a device on a network, the computer program product comprising a computer-readable medium having stored computer- readable program code for performing the steps of: receiving a message from the device, the message cryptographically signed with a device private key and including: a device identifier that is computed, using the device private key, from at least one descriptor of a hardware component associated with the device; a counter value associated with the device identifier; and a service key request; verifying the message signature using a device public key; verifying whether the received counter value is greater than a previously received counter value associated with the device identifier; generating a service key and linking the service key to the device identifier; and sending the service key to the device to enable it to communicate through secure network connections.