Authentication of data transmission devices

An intermediate data transmission device arranges for mutual authentication between itself and a remote terminal to allow data to be exchanged between the remote terminal and a server through the device. The server sends first and second key codes to the intermediate device, the key codes both being derived from a shared secret known to the server and remote terminal but not to the intermediate device. In response to a challenge from the intermediate device the remote terminal uses the shared secret to generate a duplicate of the first key code and transmits the duplicate to the intermediate device. The intermediate device compares the first key code and the duplicate of the first key code received respectively from the server and the remote terminal to verify the authenticity of the remote terminal. The intermediate device then transmits the second key code to the remote terminal, to be compared by the remote terminal with a duplicate of the second key code to verify the authenticity of the intermediate device. This process allows the intermediate device to be used without itself having the shared secret. The codes generated by the server may be encoded with a network identity of the intermediate device using the shared secret, such that the remote terminal can only respond to the same intermediate device that transmitted the codes. This prevents a “man-in-the middle” attack by another intermediate device, as without the shared secret no intermediate device can modify the codes to include a different network identity.

This application is the U.S. national phase of International Application No. PCT/EP2017/050233 filed Jan. 5, 2017 which designated the U.S. and claims priority to EP Patent Application No. 16151941.8 filed Jan. 19, 2016, the entire contents of each of which are hereby incorporated by reference.

BACKGROUND AND SUMMARY

This invention relates to the authentication of communications connections between servers and remote terminals using intermediate “mule” devices. It is particularly suited to the use of programmable wireless devices such as smart phones to collect or relay data from isolated Wireless Sensor Networks (WSNs) in a secure manner.

Mobile AdHoc-Networks or MANets have been developed and used for communication and instrumentation across battlefield, disaster area and agricultural situations where existing network capability is absent or at best intermittent. Innovative approaches have been developed to store critical data collected by sensors and forward it during brief moments of network capacity. Although network connectivity is almost ubiquitous, there are network, power and financial budgetary constraints that mean it is not possible for each remote terminal to have its own 4G wireless card and suitable battery supply to “backhaul” the data to a central data hub.

Even in urban situations, accessing suitable WiFi-capable backhaul continues to be a major obstacle to mass deployment of sensors. To address this need the concept of the data “mule” has been developed, a mobile collector or distributor device that moves through a field of interest, establishing intermittent contact with individual remote terminals, and collecting data from them for onward transmission to a central server (or, conversely, as a distributor to the remote terminals of data that has previously been downloaded to the device from a central server). Deployments typically include attachment of data mules to vehicles such as buses that collect data from roadside sensors along the route. Another application is the collection of domestic utility meter readings (water, electricity, gas, etc) by providing each premises' meter with a low-range wireless transmitter which can be read by a “mule” in a vehicle operated by the utility company as it passes through the area. The term “sensor” used in this specification includes utility meters, and any other devices which record measurements or responses to external stimuli and store the data for subsequent download.

Unlike conventional relays, the mules do not need to be in simultaneous communication with the transmitter of the data and the receiver of the destination of the data, but can store the data whilst moving out of the range of the source transmitter to the range of the receiver, through a zone out of range of both. However, this means that the source and destination cannot mutually authenticate each other's credentials.

The “mules” do not need to have access to the data they convey, but each of the three parties (server, remote terminal (sensor) and mobile device or “mule”) have to be able to authenticate to the other two that the connection between them is genuine. Existing data mule deployments are closed systems whereby the data mule and sensor network are owned and operated by the same legal entity. In such a situation, security credentials can be distributed across the closed system with a reduced risk that the information will be exposed. The data mule stores usernames, passwords or access keys that can be presented to WSN nodes during an authentication process. This approach requires very tight access to credential management. In particular, the devices to be used as mules have the access credentials of the WSN, and this requires that such devices are strictly controlled by the operator of the WSN. For instance, several mules could in principle use the same credentials, as those credentials will be transferred by the owner to each mule under strict secure conditions with very little chance of interception.

These closed systems require a dedicated fleet of mule devices and personnel to operate them. It is desirable to allow any suitably programmable communications device such as a “smartphone” to act as a data mule without a pre-established relationship with multiple WSNs. This expands the number of devices that can be used, and thus improves the data collection process. The necessary programming application (referred to herein as a DMA—data mule application), is relatively simple to install either on manufacture, or by downloading to the device subsequently, and could be installed in any Smartphone whose owner is willing to allow the device to be used in this way. Ideally the use as a “mule” would be transparent to the user and only make use of spare capacity, for example when the device is in idle mode. As with the conventional data mules, interaction with the sensor terminals may be limited to times when the mule and sensor are in close proximity, and upload of the data arranged to be at a later time when the device is in contact with the network, thus minimising the power required to operate the mule functions.

However, it is not desirable to allow a device that is not under the control of the WSN operator to be entrusted with the authentication data required for the sensors to communicate with the central data collecting server. To do so would risk compromising the security of the system as the number of such devices would proliferate. If the credentials were simply copied to thousands of third party mules under less than perfect conditions, this could result in a compromised mule (outside the control of the WSN owner) discovering and exposing the credentials to the world. The present invention addresses this problem, by providing a method for authentication of a communications connection between a server and a remote terminal using an intermediate device, in which:the server generates first and second key codes, the key codes both being derived from a shared secret known to the server and remote terminal but not to the intermediate device,the server transmits the first and second key codes to the intermediate devicethe remote terminal uses the shared secret to generate a duplicate of the first key code,the remote terminal transmits the first key code to the intermediate devicethe intermediate device compares the first key code and the duplicate of the first key code to verify the authenticity of the remote terminalthe intermediate device transmits the second key code to the remote terminalthe remote terminal uses the shared secret to generate a duplicate of the second key codethe remote terminal compares the second key code and the duplicate of the second key code to verify the authenticity of the intermediate device.

The first and second key codes may be generated dynamically from the shared secret, and changed after each use. In one variant, the server generates a plurality of one-use key code pairs and transmit them to the intermediate device, and the intermediate device uses each key-code pair in turn for a series of authentication interactions with the remote terminal. A key code may be combined with address data of the intermediate device encoded using the shared secret, so that the remote terminal may use the shared secret to decode the address data, so that another intermediate device, with a different address, cannot make connection by using the same key codes

The intermediate device may be responsive to a flag signal generated by the remote terminal to route the received data either to a data store in the intermediate device for later transmission to the server, in response to a first setting of the flag signal, or to open a connection to the server for relaying the data to the server in response to a second setting of the flag signal.

The invention also provides, in a data communications network, one or more first data communications devices for transmitting data to a server, and a second data communication device configured to operate as an intermediate relay between such a server and the one or more first data communications devices, which in combination can be configured to operate the method of the invention, and a computer program element comprising computer program code to, when loaded into a communications device and executed thereon, configure the communications device to operate in accordance with the method.

For the avoidance of doubt, it should be understood that the order of the two authentication stages can be reversed from that listed above, so that the first device verifies the authenticity of the second, intermediate, device before the second, intermediate, device verifies the authenticity of the first device.

According to this process, the application (DMA) operating on the device which is to operate as a “mule” (or relay) downloads limited authentication data from a Central Server for one or more local WSNs. The identity of the WSNs for which the device currently requires authentication data can be determined by the central server by reference to location positioning technology installed in the mobile device, such as GPS, or by the identity of the currently serving cellular network base station. The data may be arranged to be deleted from the device after a predetermined period of non-use, both for security and to avoid wasting data storage capacity in the mobile device.

When the device subsequently comes into proximity of one of the WSN terminal nodes for which it has the authentication data the DMA challenges the terminal node and, if the node returns the required response, the DMA is then required to respond to a challenge issued by the node. If the expected authentication details match those expected by the terminal node, data will be uploaded to the DMA for forwarding to the central server. However, the DMA is arranged such that it can only issue the correct challenge and recognise the required response, and return the required response to the challenge issued by the terminal node, because it has been given that information by the central server. The challenge and response are generated using “shared secrets”, shared between the central server and the respective terminal node but not the DMA. The server provides sufficient information to the DMA device to be able to issue and recognise the correct challenges and responses, but not to generate them independently of the server.

In a preferred embodiment, the challenges and responses are dynamically generated according to an algorithm derived from the shared secret, so that any rogue device that intercepts the challenge and response data cannot use it subsequently to intercept transmissions from the terminals. The preferred embodiment also encodes the address data of the mule device in communication with the terminal device, to prevent interception of the data by other devices

The data mule therefore presents authentication data to the terminal to prove that it is itself authenticated by the Central Server. In a preferred arrangement the DMA uses a network address of the mobile device as part of the encrypted “key” it uses. The terminal node uses a local algorithm to determine whether the presented “key” and mule address are consistent with a device authorised by the central server to act as a data mule in this way. The use of the MAC address (or similar network address) of the mule as part of the encrypted key means that other devices cannot emulate the genuine “mule” device as any response would only be sent to the device with the correct MAC address.

The authentication between the mule and the terminal device can be done without either of them being currently in direct contact with the central server. It is only necessary that the mule will have previously been given the necessary data to carry out the authentication when it subsequently detects a terminal device and the remote terminal will have previously been given the shared secret.

DETAILED DESCRIPTION OF PRESENT EXAMPLE EMBODIMENTS

As depicted inFIG. 1, a number of local terminals4,41,42,43,44are distributed through a region5. The functional elements of one such terminal4are depicted inFIG. 8. These terminals are provided to collect data relating to their environment through sensing apparatus81, to be stored locally (store82) and later delivered by a processing system83to a server1by way of an intermediate device3and a communications network6. A flag function800may be used to provide labelling of the data to facilitate handling by the intermediate mobile device3. Only elements relevant to the understanding of the operation of the embodiment are depicted, but it will be understood that functions such as power management would also be required.

Referring toFIG. 8in more detail, each terminal is provided with a low-powered radio transceiver80which allows it to communicate with devices nearby, but is not powerful enough to communicate directly with the nearest wireless network access point2. Each terminal also has a beacon generation system84for generating a low-powered signal advertising its presence through the radio transceiver (communications interface)80, either continuously or in response to a signal broadcast by another device such as the mobile device3. The terminal device4also includes an authentication system85, including an encryption system86including a key generation process87making use of a “shared secret” key stored in a memory88. The “shared secret” key can be installed in the terminal when it is first deployed. The terminals are configured to operate in accordance with steps106-109and112-118of the process to be described later, with reference toFIG. 5.

The central server1depicted inFIG. 6has a processor66configured to operate in accordance with steps101-105and123-126of the process to be described later, with reference in particular toFIG. 4, and in particular to collect data from the terminals (step123) and process the data so collected (step126). It also has a copy of the “shared secret” key88for each terminal4,40,41etc, to be used by a key generation system62to generate request keys and challenge keys to be stored (store63) for use in a decryption function65of data received from the remote terminals,4,40,41etc through the interface64from the network6. As will be explained, the key store also generates key codes for transmission through the communications interface64to the mobile devices3. The central server also maintains a store68of location data for the terminals4,40,41etc.

FIG. 6depicts an interface69with a billing system67for managing a user account associated with each mobile device3, which is used in some embodiments.

The various functional elements depicted inFIG. 6as co-operating in operation as the server may form part of a distributed system, and are not necessarily co-located.

A “Data Mule Application” (DMA) is installed on a mobile device3to allow it to act as a relay between the terminals4,41,42etc and the central server1, when the mobile device is within range of one of the terminals, in accordance with steps100,101,105-107,109-112and118-123of the process, to be described later with reference toFIG. 3. The mobile device may be a conventional “smartphone”, with the typical components including a user interface74, central processor73, an app store70for programming data, and a communications interface71. The communications interface71is capable of wireless communication with the network2and the terminal devices4.

The “data mule application” can be installed in the application store70on the device during manufacture, or downloaded subsequently by the central server1from an application store60, (as shown inFIG. 6), or from some other source. The “data mule application” stored in the application store70is then used to control the central processor73of the mobile device3according to the programme data in the application to retrieve data from, or send configuration data to, the terminals4,40, . . . , either to forward directly to the server1or to store in a temporary data store78until it is possible to forward it to the server1.

The application includes a location-finding system72for identifying the general area in which the mobile device3is currently located. The location-finding system may use an input from, for example, a GPS system, or it may be associated with the communications interface71, reporting its position to the server1with reference to its location relative to the fixed infrastructure of the network2. The application also includes a beacon detection function75and an authentication processor76, including a store77for downloaded authorisation data.

Such a mobile device3is depicted inFIG. 1travelling on a trajectory30,31,32,33,34which passes through the region5in which the terminals are located. As the device approaches the region (position31), it provides location data (72) to the server1which retrieves data68relating to any terminals4,41,42. . . in that area and the key generation system62generates authentication data relating to those terminals and transmits it via the interface64,2,71to the data store77associated with the authentication processor76running on the processor73of the mobile device3. A flag detector700may be provided to process control information relating to the handling of the data, for example whether to forward it immediately or store it in local memory78until the device next connects to the network2. The use of such a flag is particularly useful if the data itself is encrypted in such a way that the mobile device3cannot parse it.

As has already been discussed with reference toFIG. 8, each terminal4has a beacon generation system84for generating a low-powered signal advertising its presence. Referring toFIGS. 1 and 2, if the mobile device3comes within range of such a beacon signal (e.g. location32) the mobile device3interrogates the terminal4to allow retrieval of data or the distribution of configuration data or software to the terminal. This process is repeated for any other terminal41whose beacon it detects (position33). The data may then be uploaded by the mobile terminal3to the central server1using the access network2,6, The data may be stored in the mobile device3at a temporary store78(FIG. 7) for transmission to the server1at a subsequent time (location34) if it is impossible or inconvenient to set up a special data session with the access network2,6immediately the data has been collected.

In order to allow mobile devices not under direct control of the operator of the terminals4,41etc, and the central server1to be used for this purpose, it is desirable for each of the three elements in the process—that is to say the central server1, the mobile device3and the terminal4—to be able to authenticate the identities of the other two. This is achieved, in the present embodiment, by the following process. It will be described with reference to a single terminal device4, but it will be understood that the process will be the same for all the other terminal devices41,42, etc.

Each local terminal (LS) has a “shared secret” key (SK), identical copies of which are stored securely in memory in the central server1(FIG. 6) and in memory in the terminal4(FIG. 8) (both indexed “88” as the data in the memories are identical). It is desirable that each terminal4,41,42etc has a different “shared secret”, each known only to central server1and the respective terminal. This secret key can be used to generate encryption key strings without compromising the secret, but the generated key strings can only be decrypted by a device that also has the shared secret. It is desirable that the secret is derived from an algorithm such as Time-based One-time Password Algorithm (TOTP), that computes a one-time password from the shared secret key and the current time and/or a counter, to generate a hash-based message authentication code (HMAC), such that it changes with each use in a quasi-random manner, to ensure that any user intercepting communications using the key cannot use the intercepted communication as a model for a rogue communication emulating the genuine originator of the original message.

The authentication process will be described with reference toFIGS. 1 to 5. There are two principal stages to the process. The first stage, (Steps100-105) takes place in response to a mobile device3moving to a location31within an area5where there are terminals4,41, etc to be detected. In this stage, the mobile device is given information to allow it to identify the terminals and perform a mutual authentication with them The second stage (steps106-123) takes place in response to the mobile device, having moved to a location32,33in which it detects the beacon of one of the terminals4,41etc), and can carry out the authentication process for which it was given the necessary data in the first stage.

The process operates as follows. The mobile unit3is configured to report to the central server1when its location-finding system72detects that it has entered a region5where terminals4,41etc under the indirect control of the server are located. This may be done by having the mobile device3periodically reporting its position to the server1, and the server responding when the reported location meets predetermined criteria. Alternatively, the position-based criteria can be pre-loaded in the programming70of the mobile device, so that when the location system72detects that its location is within a region5, it automatically reports to the central server1.

When the mobile unit3enters such a predetermined region5(step100) its authentication processor76co-operates with the central server1, and as a first step in the process it requests a “white list” of local terminals (step101). This request includes the MAC address of the mobile device, and its current location. The use of the MAC address of the data mule when generating a one time or many-time challenge key effectively binds the data mule3with the server1.

The central server1retrieves the data relating to the relevant terminals4,40,41etc from a store68and generates a request transaction identity (r_txid) and a challenge transaction identity (c_txid) for each terminal4,41,42etc in the region5(step102). (Apart from using different secret keys, the process is the same for each terminal and will be described only for terminal4). The c_txid is a quasi-random string generated using the secret key SK of the terminal4and information specific to the device3such as such as MAC address, serial number and vendor. The r_txid is another quasi-random string, also generated using the secret key and the device-specific data, and also includes the MAC address of the terminal4.

The key generation processor62then generates a request key (RK) for the terminal, incorporating the r_txid (step103), and a challenge key (CK) for the terminal incorporating the c_txid (step104). Each request key is unique and is generated using an encrypted form of the MAC address of the mobile device as one of the parameters, other parameters may include time validity (earliest and latest times), trust level (access control on what the mule can access), number of authentication attempts allowed, and unique transaction identifier. This prevents other devices eavesdropping on exchanges between the mobile device3and the terminals4and then replaying the exchange substituting their own MAC address. It should be noted that as only the terminal4and the central server1have access to the “secret key” (SK)88, no mobile device can generate the encrypted form of the MAC address for itself, nor for any other mobile device it may be attempting to emulate (“spoof”).

The keys can be implemented using Keyed Hash Message Authentication Code (HMAC) algorithm such as HMAC-MD5 or HMAC-SHA1. Effectively, the smart phones Bluetooth MAC (comprising 6 bytes) address (and or serial number/vendor) and r_txid can be combined with a shared secret message SK (known only to terminal and central server) into a single plain-text message. The plain message can then be hashed using the SK (known only to terminal and central server) to produce a message digest. This message digest is effectively the RK. Likewise, the CK can be generated in the same way using the c_txid.

The use of transaction identities (txid) is desirable to prevent Man-in-the-Middle attacks, terminal spoofing and replay attacks. In effect, the txids allow the uses of each request key (RK), and challenge key (CK) to be limited in number or period of validity.

Setting up the system to use-keys-only-once would prevent replay attacks by eavesdropping devices, because once authentication has occurred once, the key becomes invalid and no further device listening in would be able to use the same key to gain access. To accomplish this, the terminal4and central server1maintain previously used r_txids relating to each mobile device in memory63,89for long enough for the threat of immediate “replay” attacks using the same r_txid to have subsided.

Likewise, the terminal4can store used c_txids for the mobile device3in memory89, so that it can detect when a “spoofer” device is attempting to replay a previous challenge request.

The central server1next transmits a message to the mobile device3with the request key RK, challenge key CK, and also incorporating the respective identities r_txid and c_txid (step105) from which they were generated, for each terminal on the “white list”68for the locality identified. The mobile device3then stores this data77until required. Likewise, terminal-specific configuration data or software could also be sent to the device3to allow updates to be made to the terminal.

In one variant, the central server1downloads to the terminal4a set of one-off RK, CK each with an associated txid, that can be used as a set of one-time “vouchers” to authenticate with the terminal. This allows the mobile device3to make multiple contacts with the same terminal4without the need to contact the server1between each such contact. Essentially, the central server1has given the mobile device3instructions77on how to recognise, and be recognised by, the terminal4, but without releasing the shared secret stored in the respective memories88of the terminal and server by which the recognition signals have been generated. The mobile device3(or “mule”) only sees the public keys (RK, CK) and does not share the secret which allows such keys to be generated. Furthermore, each key can only be used once, and only by the device having the MAC address encrypted into the key.

The instructions sent by the server1provide the data required to allow the mobile device3to set up a two-way authentication process between the mobile device3and the terminal4. The set-up process enables the mobile device to issue an initial challenge (Q), recognise the correct response (R) from the terminal, and generate a counter-response (C). The response R is sufficient to prove to the mobile device that the terminal is genuine as only a terminal having the “shared secret” available in its memory88can derive response R from challenge Q. The counter-response C is sufficient to prove to the terminal that the device transmitting it is also genuine, as the correct counter-response can only have been generated by the server1with the shared secret88, and thus provides confirmation that the mobile unit has been authorised by the server to receive data from the terminal.

The use of the challenge Q, response R and counter-response C, will now be discussed with reference toFIGS. 2, 3, and 5(steps106-122)

Each terminal4,41, etc transmits a beacon signal generated by the beacon generator84at low power so that when a mobile device is close to it, communication can be established between the terminal and the mobile device. By using the mobile unit3as a relay, the power required for transmission can be much reduced compared with transmission direct to the central server1through a “wi fi” hotspot or a cellular base station2.

When the mobile device3approaches a terminal it detects the MAC address of the terminal in its beacon signal84(step106) and pulls the appropriate terminal information from its white list77. The authentication process76in the mobile device3generates a challenge request Q (step107) using the c_txid authorisation data77and sends it to the terminal4.

The authentication processor85in the terminal4then generates a copy CK* (A1) of the challenge key (step108), calculated by using the “shared secret” key SK to decrypt the information in the challenge request c_txid received from the mobile device3. This copy CK* is returned to the mobile device (step109).

In the next step110the authentication processor76in the mobile device3then compares the challenge key CK* received from the terminal4(in step109) with the challenge key CK previously received from the central server (in step105) and stored in the memory77. If CK and CK* correspond then this is proof that the terminal4is genuine (step111), because it shares the secret code SK with the central server1, as the key CK/CK* can only be derived if the secret code SK is known. It should be noted that the mobile device3does not itself have access to the secret code SK, but can determine that both the central server and the terminal can independently derive the code CK/CK*.

Likewise, the authentication processor76in the mobile device3sends an authentication request to the terminal4including the MAC address, and r_txid (step112). It also sends the request key RK. It should be noted that the value of RK transmitted by the mobile device was generated from the r_txid by the central server1using the secret key SK. The mobile device, not having access to the secret key SK, cannot generate the value of the r_txid independently of the server1. Moreover, as the request key RK also includes the MAC address of the mobile device3, encrypted using the secret key, other mobile devices cannot stage a “man in the middle” attack on the communications as it does not have access to the key by which the correct MAC address could be substituted by that of the attacking device.

Using the MAC address of the mobile device3, the r_txid, and the secret key SK, the authentication processor85in the terminal4determines a value for the request key RK* (step113). This is compared (step114) with the value of RK received from the mobile device3in the previous step. If the RK received in the authentication request112and the locally generated RK* (generated in step113) match, the terminal can determine that the mobile device3is genuine, as the mobile device3can only provide the correct value for RK if that value has been generated by the secret code SK, and therefore must have been received from the server1.

The mobile device3and the terminal4having each determined that the other is a genuine part of the network under the control of the server1, communication can be opened between the data store82in the terminal4and the data store61in the server1, through the mobile device3(step118). Further security for the data itself may be provided by providing an encrypted “tunnel” through the mobile device3between the data processing function83of the terminal4and the corresponding data processing function66of the server1. The data processing encompasses retrieval of terminal data but also the distribution of configuration or update software or data to the terminal. The device acting as “mule” does not need to have access to the encryption system, but is merely the means by which the encrypted data is carried between the terminal and the central server, where it can be decrypted so that the central server1can process the data (step126)

In some cases, the terminal4may apply a flag800to identify the data (flag RMK, steps116,117) as being of high priority, for example to report a failing power supply, loss of the terminal network or a critical value having been detected, requiring immediate upload to the central server1. The flag RMK can be created using the same key-creation principles as discussed above. If a flag detection unit700in the mobile device3detects the priority flag RMK (step119) it establishes a connection with the network immediately (step120), whereas other data messages may be stored in memory78(step121) until the mobile device3next connects to a network for the user's own purposes (step122).

The application running on the device3may face penalties such as connection or data volume charges when using 3G/4G networks. A remuneration system may be provided such that the owner-operator of the mobile device can be compensated for any additional connection charges incurred. To prove the high priority of the request, the high priority flag RMK may thus be forwarded by the mobile device3to the central server1(step124) with the data. Detection of this flag may be used by a billing interface69to cause the transmission of data to a billing system67(step125) to compensate the user of the terminal3for the additional connection required by the data download, for example by crediting the user's account with the cost of the data session.