SE2251489A1

SE2251489A1 - Enabling communication between a client device and a field device

Info

Publication number: SE2251489A1
Application number: SE2251489A
Authority: SE
Inventors: Frans Lundberg
Original assignee: Assa Abloy Ab
Priority date: 2022-12-19
Filing date: 2022-12-19
Publication date: 2023-12-12

Abstract

It is provided a method for enabling communication between a client device (1) and a field device (2). The method comprises: generating (40) a temporary keypair; signing (41), based on a long-term secret key forming part of a long-term keypair of the field device, a data item comprising the temporary public key, yielding a signature; sending (42) a message comprising the data item and the signature to a coordinator device (3); obtaining (142) the temporary public key for the field device (2) from the coordinator device (3), generating (144) a request, which comprises encrypting the request based on the temporary public key for the field device (2); transmitting (146) the request to the coordinator, for forwarding the request to the field device (2); receiving (43) the request, originating from the client device (1); and decrypting (47) the request using the temporary private key.

Description

TECHNICAL FIELD id="p-1" id="p-1" id="p-1"

[0001] The present disclosure relates to the field of electronic communication, and in particular to enabling communication between a client device and a field device.

BACKGROUND id="p-2" id="p-2" id="p-2"

[0002] Traditional online remote procedure calls (RPC) are used when a client and a server have a reliable communication link between each other. A typical scenario is a client and a server connected to the Internet. The client connects to the server using Internet Protocol (IP) to route the data packets to the server. A reliable, bi-directional communication channel is established between the parties, typically using transport control protocol (TCP) and then a secure channel is established on top of that, e.g. using transport layer security (TLS). The secure channel provides security features such as confidentiality, mutual authentication, ephemeral encryption (achieving forward secrecy using temporary encryption keys), and protection against replay attacks. id="p-3" id="p-3" id="p-3"

[0003] Because of modern computer network routing (based on IP) and the protocols to establish a reliable and secure communication channel (TCP, TLS), the client software and the server software seemingly communicate with each other directly.

The client and the server application do not need to consider routing, how to send data between them, since that is provided using the underlying protocols. id="p-4" id="p-4" id="p-4"

[0004] However, not all devices are constantly online, e.g. field devices that are resource-constrained and often powered by batteries or energy harvesting. How can a client connect to such a field device in a secure manner when it is not possible to establish an online communication channel between the client and the field device? SUMMARY id="p-5" id="p-5" id="p-5"

[0005] One object is to provide improved security for communication with devices that are, at least part of the time, ofﬂine. id="p-6" id="p-6" id="p-6"

[0006] According to a first aspect, it is provided a method for enabling communication between a client device and a field device. The method comprises: generating, by the field device, a temporary keypair comprising a temporary public key and a temporary private key; signing, by the field device, based on a long-term secret key forming part of a long-term keypair of the field device, a data item comprising the temporary public key, yielding a signature; sending, by the field device, a message comprising the data item and the signature to a coordinator device; obtaining, by the client device, the temporary public key for the field device from the coordinator device; generating, by the client device, a request, which comprises encrypting the request based on the temporary public key for the field device; transmitting, by the client device, the request to the coordinator, for forwarding the request to the field device; receiving, by the field device, the request, originating from the client device; and decrypting, by the field device, the request using the temporary private key. id="p-7" id="p-7" id="p-7"

[0007] According to a second aspect, it is provided a method for enabling communication between a client device and a field device, the method being performed in the field device. The method comprises: generating a temporary keypair comprising a temporary public key and a temporary private key; signing, based on a long-term secret key forming part of a long-term keypair of the field device, a data item comprising the temporary public key, yielding a signature; sending a message comprising the data item and the signature to a coordinator device; receiving a request, originating from the client device; and decrypting the request using the temporary private key. id="p-8" id="p-8" id="p-8"

[0008] The method may further comprise, after the receiving a request: obtaining a sequence indicator from the request; determining the request to be invalid when the sequence indicator is the same as for a previously received request; and storing a record of the sequence indicator in a data structure. id="p-9" id="p-9" id="p-9"

[0009] The data structure may be in the form of a sequence of bits, wherein each bit corresponds to a single sequence indicator. id="p-10" id="p-10" id="p-10"

[0010] The method may further comprise: performing an action based on the decrypted request; and transmitting a response message based on the result of the action. 3 id="p-11" id="p-11" id="p-11"

[0011] The method may further comprise, prior to the transmitting a response: generating a response based on the result of the action, which comprises encrypting the response based on a temporary public client key obtained from the decrypted request. id="p-12" id="p-12" id="p-12"

[0012] The step of generating a response may comprise including the message in the response, in which case the sending of the message is performed by the transmitting the response. id="p-13" id="p-13" id="p-13"

[0013] According to a third aspect, it is provided a field device for enabling communication between a client device and the field device. The field device comprises: a processor; and a memory storing instructions that, when executed by the processor, cause the field device to: generate a temporary keypair comprising a temporary public key and a temporary private key; sign, based on a long-term secret key forming part of a long-term keypair of the field device, a data item comprising the temporary public key, yielding a signature; send a message comprising the data item and the signature to a coordinator device; receive a request, originating from the client device; and decrypt the request using the temporary private key. id="p-14" id="p-14" id="p-14"

[0014] According to a fourth aspect, it is provided a computer program for enabling communication between a client device and the field device. The computer program comprises computer program code which, when executed on a field device causes the field device to: generate a temporary keypair comprising a temporary public key and a temporary private key; sign, based on a long-term secret key forming part of a long-term keypair of the field device, a data item comprising the temporary public key, yielding a signature; send a message comprising the data item and the signature to a coordinator device; receive a request, originating from the client device; and decrypt the request using the temporary private key. id="p-15" id="p-15" id="p-15"

[0015] According to a fifth aspect, it is provided a computer program product comprising a computer program according to the fourth aspect and a computer readable means comprising non-transitory memory in which the computer program is stored. id="p-16" id="p-16" id="p-16"

[0016] According to a sixth aspect, it is provided a method for enabling communication between a client device and a field device. The method is performed in 4 the client device. The method comprises: obtaining a temporary public key for the field device from a coordinator device; generating a request, which comprises encrypting the request based on the temporary public key for the field device; and transmitting the request to the coordinator, for forwarding the request to the field device. id="p-17" id="p-17" id="p-17"

[0017] The method may further comprise: obtaining a temporary keypair for the client device, the temporary keypair comprising a temporary public key and a temporary secret key. In this case, the generating the request comprises including the temporary public key for the client device in the request. id="p-18" id="p-18" id="p-18"

[0018] The method may further comprise: receiving a response from the field device, routed via the coordinator device; decrypting the response using the temporary secret key for the client device. id="p-19" id="p-19" id="p-19"

[0019] According to a seventh aspect, it is provided a client device for enabling communication between a client device and a field device. The client device comprises: a processor; and a memory storing instructions that, when executed by the processor, cause the client device to: obtain a temporary public key for the field device from a coordinator device; generate a request, which comprises encrypting the request based on the temporary public key for the field device; and transmit the request to the coordinator, for forwarding the request to the field device. id="p-20" id="p-20" id="p-20"

[0020] According to an eighth aspect, it is provided a computer program for enabling communication between a client device and a field device. The computer program comprises computer program code which, when executed on a client device causes the client device to: obtain a temporary public key for the field device from a coordinator device; generate a request, which comprises encrypting the request based on the temporary public key for the field device; and transmit the request to the coordinator, for forwarding the request to the field device. id="p-21" id="p-21" id="p-21"

[0021] According to a ninth aspect, it is provided a computer program product comprising a computer program according to the eighth aspect and a computer readable means comprising non-transitory memory in which the computer program is stored. id="p-22" id="p-22" id="p-22"

[0022] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/ an /the element, apparatus, component, means, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS id="p-23" id="p-23" id="p-23"

[0023] Aspects and embodiments are now described, by way of example, with refer- ence to the accompanying drawings, in which: id="p-24" id="p-24" id="p-24"

[0024] Fig 1 is a schematic diagram illustrating an environment in which embodiments presented herein can be applied; id="p-25" id="p-25" id="p-25"

[0025] Fig 2 is a swimlane diagram illustrating embodiments of methods for enabling communication between a client device and a field device; id="p-26" id="p-26" id="p-26"

[0026] Fig 3 is a schematic diagram illustrating components of the client device, the field device and the coordinator device of Fig 1; and id="p-27" id="p-27" id="p-27"

[0027] Fig 4 shows one example of a computer program product comprising computer readable means.

DETAILED DESCRIPTION id="p-28" id="p-28" id="p-28"

[0028] The aspects of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown. These aspects may, however, be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and to fully convey the scope of all aspects of invention to those skilled in the art. Like numbers refer to like elements throughout the description. id="p-29" id="p-29" id="p-29"

[0029] According to embodiments presented herein, secure communication with field devices is provided. Specifically, support for temporary (also known as ephemeral) keypairs is provided with assistance from a coordination device. The coordination device stores the public key of the current ephemeral keypair for each field device, allowing a client to encrypt communication to the field device without the risks associated with applying encryption using static encryption keys. Optionally, the coordinator also provides sequencing of requests, verified by the field device, to prevent replay attacks or issues that can occur with multi-route communication. id="p-30" id="p-30" id="p-30"

[0030] Fig 1 is a schematic diagram illustrating an environment in which embodiments presented herein can be applied. id="p-31" id="p-31" id="p-31"

[0031] There is a need for a client device 1 to communicate with a field device 2. The client device 1 can be any suitable electronic device that benefits from communication with the field device 2. For instance, the client device 1 can be a smartphone, tablet computer, wearable device, laptop computer, desktop computer or server. id="p-32" id="p-32" id="p-32"

[0032] The field device 2 is any electronic device benefitting from communication provided by embodiments presented herein. The field device 2 can be resource- constrained and can be powered by a battery. In one example, the field device 2 is powered (or even only powered) by energy harvesting. In one example, the field device 2 is powered only by an incoming wireless signal, e.g. based on radio frequency identification (RFID) or near-field communication (NFC). The field device 2 can be a sensor and/ or actuator in the context of Internet-of-Things (IoT). For instance, the field device 2 can be an ofﬂine lock, an intrusion sensor, a smoke detector, or a digital thermometer, etc. The field device 2 can be completely ofﬂine, partly online, or mostly online. The field device 2 does not need to have a real-time clock. id="p-33" id="p-33" id="p-33"

[0033] A coordinator device 3 is a server that is online (i.e. connected to the Internet or similar). The coordinator device 3 is used to enable communication between the client device 1 and the field device 2 as described in more detail below. id="p-34" id="p-34" id="p-34"

[0034] A routing network 8 enables messages to be routed from the coordinator device 3 to the field device 2 or vice versa. The routing network 8 can be based on temporarily available nodes, e.g. smartphones that can act as an intermediary node for store-and-forward routing to the field device 2, when the smartphone connects locally 7 with the field device 2. It is to be noted that, at the time of communicating with the field device, such a smartphone can be ofﬂine. id="p-35" id="p-35" id="p-35"

[0035] The client device 1 sends requests to the field device 2 and receives responses back. Unlike the case of online RPC, the lifetime of a request-response interaction can be days instead of seconds. And the communication is store-and-forward via the coordinator device 3 and a routing network 8. id="p-36" id="p-36" id="p-36"

[0036] Since the field device 2 can be ofﬂine when the client device 1 sends a request, the coordinator device 3 is provided to store and forward the request sent by the client device 1. The coordinator device 3 is online and alleviates problems caused by the client device 1 and/ or the field device 2 being ofﬂine. id="p-37" id="p-37" id="p-37"

[0037] The client device 1 communicates with the coordinator device 3, e.g. over the Internet. Since the field device 2 may be ofﬂine when the coordinator device 3 receives a request from the client device 1, the coordinator device 3 forwards the request when possible via the routing network 8, and stores the request when the forwarding is not possible. id="p-38" id="p-38" id="p-38"

[0038] The coordinator device 3 performs routing to enable that a request from the client device 1 get to the field device 2 and the corresponding response gets back. Consider our example of an NFC-powered ofﬂine lock. To make this problem even harder, assume the smartphones connecting to the lock are also ofﬂine when connecting to the lock (over NFC). Consider a particular request by the client device 1. It may be a request to add a user to the lock. The coordinator device 3 can then route the request to the lock by sending copies of the request to multiple smartphones. the coordinator device 3 keeps track of what smartphones that often connects to the lock and predicts the likelihood of particular smartphones connecting to the lock the next time. This is an example of multi-path routing. The request is sent to multiple smartphones to increase the likelihood of the response getting to the field device 2 as soon as possible and as reliable as possible. 8 id="p-39" id="p-39" id="p-39"

[0039] The routing algorithm can differ depending on the specifics of the available communication paths between the coordinator device 3 and the field device 2 in question. id="p-40" id="p-40" id="p-40"

[0040] The request eventually gets to the field device 2, is then processed, and a corresponding response is routed back via the routing network 8 and the coordinator device 3 to the client device 1. id="p-41" id="p-41" id="p-41"

[0041] Fig 2 is a swimlane diagram illustrating embodiments of methods for enabling communication between a client device 1 and a field device 2. The swimlane diagrams can be considered to comprise a ﬂow chart for methods in the client device 1 on the left, a ﬂow chart for methods in the coordinator device 3 in the middle, and a ﬂow chart for methods in the field device 2 on the right. Communication between the entities is also shown. id="p-42" id="p-42" id="p-42"

[0042] In a generate temporary keypair step 40, the field device 2 generates a temporary keypair comprising a temporary public key and a temporary private key. The temporary keypair is also known as an ephemeral keypair and can be used in asymmetric cryptography. For example, it can be used for cryptographic signing or for performing Diffie-Hellman computations. id="p-43" id="p-43" id="p-43"

[0043] In a sign step 41, the field device 2 (cryptographically) signs a data item comprising the temporary public key, yielding a signature. The signing is based on a long-term secret key (also known as a static secret key) forming part of a long-term keypair of the field device 2. The public key of the long-term keypair is previously distributed to e.g. the coordinator device 3 to allow verification of cryptographic signatures applied using the long-term secret key. id="p-44" id="p-44" id="p-44"

[0044] In a send message step 42, the field device 2 sends a message 20 comprising the data item and the signature to a coordinator device 3. The message can be sent whenever the field device 2 is able to send off messages to the coordinator device 3, e.g. via local communication to a local device (e.g. smartphone or wearable device) that is temporarily in the vicinity of the field device 2 and that communicates with the field device 2 for any purpose. The local communication can e.g. be based on NFC, RFID, 9 Bluetooth, Bluetooth low energy, or any other suitable communication protocol allowing communication between the field device 2 and the local device. As explained below, the message can e.g. be sent in conjunction with sending a response to a request from a client, thereby allowing the ephemeral public key to evolve over time and be propagated to the coordinator device 3. id="p-45" id="p-45" id="p-45"

[0045] In a store temporary public key step 240, the coordinator device 3 stores the temporary public key of the field device 2 which forms part of the data item of the message received from the field device 2. The coordinator device 3 can verify the authenticity of the temporary public key by verifying the signature in the message against a long-term public key of the long-term keypair of the field device 2. id="p-46" id="p-46" id="p-46"

[0046] In an optional obtain temporary keypair for client device step 140, the client device 1 obtains a temporary keypair for the client device. The temporary keypair for the client device comprises a temporary public key and a temporary secret key. This can be obtained by the client device generating the temporary keypair for the client device. id="p-47" id="p-47" id="p-47"

[0047] In an obtain temporary public key step 142, the client device 1 obtains the temporary public key 20" for the field device 2 from the coordinator device 3, e.g. using IP communication between the client device 1 and the coordinator device 3, which can occur via the Internet. id="p-48" id="p-48" id="p-48"

[0048] When online RPC can be applied, encryption is handled by a secure channel. Ephemeral (temporary) encryption is achieved on a per-session basis. In each session, both the client device the server create temporary key pairs used only for the session. The public keys of the temporary key pairs are exchanged in the session handshake when the secure channel is established. However, in embodiments presented herein, there is no handshake phase. The client device 1 can create and send a request even if the receiver the field device 2 is ofﬂine. The temporary encryption is instead achieved using the temporary public key stored by the coordinator device 3. id="p-49" id="p-49" id="p-49"

[0049] In a generate request step 144, the client device 1 generates a request. This comprises encrypting the request based on the temporary public key for the field device 2. By encrypting the request, no node between the client device 1 and the field device 2 1O can read the content of the request. Also, since the encryption is based on the temporary public key, an attacker could not decrypt the request based on a static secret key of the field device 2 or a future/ past temporary public key of the field device 2. The request is generated by the client device 1 to in some way communicate with the field device 2, e.g. for the field device 2 to execute a command, provide data, etc. For instance, when the field device 2 is an electronic lock, the client device 1 can use the request to update access rights in the electronic lock or to request an access log. When step 140 is performed, the request can also comprise the temporary public key for the client device, of the temporary client keypair obtained by the client device 1, to enable encryption of data in a response from the field device 2 to the client device 1. id="p-50" id="p-50" id="p-50"

[0050] In a transmit request step 146, the client device 1 transmits the request 21 to the coordinator 3, for forwarding the request to the field device 2. The communication between the client device 1 and the field device 2 can occur using IP communication, e.g. over the Internet. id="p-51" id="p-51" id="p-51"

[0051] Regarding protection against replay attacks, when online RPC can be applied, secure ordering of request and protection is provided by the secure channel. When such a secure channel is not available, such as for embodiments presented herein, another solution is needed. It is not enough to just forward a signed and encrypted request to the field device 2, since this will not protect against replay attacks; the same request could be presented multiple times to the field device 2 and it could then be executed multiple times, which should be avoided. Consider e.g. when the request causes an electronic lock to unlock; such a request should be prevented from being replayed at a later stage. Furthermore, in some cases, the ordering of the requests is important. A man-in-the middle attacker should not be able to change the order of the requests. id="p-52" id="p-52" id="p-52"

[0052] In an apply sequencing step 242, the coordinator device 3 appends a sequence indicator to the request. In other words, the coordinator device 3 will give each incoming request, for a particular field device 2 (regardless of the identity of the client device 1), a sequence indicator. The sequence indicator can be sequence number (e.g. 0, 1, 2, ...). Such sequencing is reliable since all requests to the field device 2 pass via the coordinator device 3. Optionally, the coordinator device 3 also adds a timestamp of the 11 current time to each request. Optionally, the sequence indicator and/ or timestamp form part of a data item that is signed by the coordinator device 3. id="p-53" id="p-53" id="p-53"

[0053] In a forward step 244, the field device 2 forwards the request 21, via the routing network 8 to the field device 2. id="p-54" id="p-54" id="p-54"

[0054] It is to be noted that the coordinator device 3 does not need to know anything about the contents of the requests (and any subsequent responses). The requests are encrypted for the field device 2 and the responses are encrypted for the client device 1. the coordinator device 3 only needs to know the identity of the field device 2 (for example its public key) to route the request correctly. The field device 2 trusts the coordinator device 3 (verified by verifying the signature applied by the coordinator device 3) for any timestamping and/ or sequence numbering that is applied. Beyond that, the coordinator device 3 does not need to be trusted. The coordinator device 3 can be a generic online service for performing the role described herein. Just like routers on the Internet (e.g. for TLS), the coordinator device 3 only sees the address to route to, it does not see the contents of the data because it is encrypted for the receiver. id="p-55" id="p-55" id="p-55"

[0055] Nevertheless, the coordinator device 3 can keep information about how to best route messages, just like Internet routers do. id="p-56" id="p-56" id="p-56"

[0056] In a receive request step 43, the field device 2 receives the request 21, that originates from the client device 1. The request can be received over local communication from a device (e.g. smartphone or wearable device) in the vicinity of the field device 2. id="p-57" id="p-57" id="p-57"

[0057] In an optional obtain sequence indicator step 44, the field device 2 obtains a sequence indicator from the request. id="p-58" id="p-58" id="p-58"

[0058] In an optional conditional valid sequencing step 45, the field device 2 determines whether the sequence indicator is valid. The request is considered to be invalid when the sequence indicator is the same as for a previously received request. id="p-59" id="p-59" id="p-59"

[0059] The check of the sequencing can be made against a data structure being a sequence of bits, wherein each bit corresponds to a single sequence indicator. In other 12 words, the data structure can be a bitmap that functions as a circular buffer of bits, indexed by the request sequence number. For example, by storing a bitmap using only 200 bytes of memory (plus data for storing the offset from zero for the first sequence number), the field device 2 can store information about whether the last 1600 (200 bytes X 8 bits per byte) requests have been processed or not. This allows the field device 2 to protect against replay attacks. If the bit corresponding to an incoming request has been set already, it indicates that the request has been processed and the request will not be processed again. Not only does this protect against a replay attack by a malicious attacker, but it also protects against replay by benevolent participants when multi-path routing is used. This can occur when the coordinator device 3 routes a request via multiple participants (e.g. smartphones). This means that multiple participants may present the request to the field device 2 even when all behave benevolent. id="p-60" id="p-60" id="p-60"

[0060] It is to be noted that the embodiments for sequencing can be applied without the embodiments presented for encryption using temporary keypairs. id="p-61" id="p-61" id="p-61"

[0061] Optionally, the field device 2 validates the signature applied to the sequence indicator by the coordinator device 3, using a public key of the coordinator device 3. When a timestamp is appended to the request by the coordinator device 3, the field device 2 can protect against request that passed its time-to-live. The current time, if no clock is available in the field device 2, can be provided by the device in communication with the field device 2, such as an intermediary smartphone. id="p-62" id="p-62" id="p-62"

[0062] When the request is determined to be invalid, the method ends. Otherwise, the method proceeds to a store record step 46. id="p-63" id="p-63" id="p-63"

[0063] In the store record step 46, the field device 2 stores a record of the sequence indicator in a data structure, such as the data structure mentioned above. id="p-64" id="p-64" id="p-64"

[0064] In a decrypt step 47, the field device 2 decrypts the request using the temporary private key. Optionally, the field device 2 keeps a set number of temporary keypairs, if the client device 1 is not synchronised with the most current temporary public key of the field device 2. For instance the field device 2 can keep the three most recent temporary keypairs at any point in time. 13 id="p-65" id="p-65" id="p-65"

[0065] The entire encryption process thus works according to following, with reference to the steps above. In step 40, the field device 2 periodically creates a new temporary (ephemeral) key pair. The public key of the temporary key pair is signed using the static key pair of the field device 2 in step 41, and is then sent to the coordinator device 3 in step 42. The coordinator device 3 stores the current temporary public key in step 240 in a database (for any suitable number of field devices). When the client device 1 is about to send a request to the field device 2, the client device 1, in step 142, makes a lookup in the database of the coordinator device 3 to obtain the most recent temporary public key of the field device 2 before the request is created. The request is encrypted in step 144 for the temporary key pair of the field device 2 (i.e. not for the static key pair of the field device 2). Only the temporary key pair of the field device 2 will be able to decrypt the generated message. Once this temporary key pair is discarded (e.g. when a new temporary keypair is generated in step 40), no one can decrypt messages sent using this key pair. Thus, temporary encryption for requests is achieved without the need for an online communication channel between the client device 1 and the field device 2. id="p-66" id="p-66" id="p-66"

[0066] In an optional perform action step 48, the field device 2 performs an action based on the decrypted request. id="p-67" id="p-67" id="p-67"

[0067] In an optional generate response step 49, the field device 2 generates a response based on the result of the action, which comprises encrypting the response based on a temporary public client key obtained from the decrypted request. id="p-68" id="p-68" id="p-68"

[0068] In an optional transmit response step 50, the field device 2 transmits a response message 22 based on the result of the action. It is to be noted that, achieving temporary encryption of the responses is simpler than for the requests. Each request contains the public key of a temporary key pair that the client device 1 created specifically for the request. The response from the field device 2 is encrypted for this temporary key pair, not for the static key pair of the client device 1. id="p-69" id="p-69" id="p-69"

[0069] Optionally, the generate response step 49 comprises including the message in the response. In this case, the send message step 42 is performed by the transmít response step 50. In this way, the public keys of the temporary key pairs created by the 14 field device 2 are sent piggy-back with the responses being sent. This may optimize the routing compared to sending them separately. id="p-70" id="p-70" id="p-70"

[0070] In an optional forward step 246, the coordinator device 3 forwards the response 22 to the client device 1. id="p-71" id="p-71" id="p-71"

[0071] In an optional receive response step 148, the client device 1 receives the response from the field device 2, routed via the coordinator device 3. id="p-72" id="p-72" id="p-72"

[0072] In an optional decrypt step 149, the client device 1 decrypts 149 the response using the temporary secret key for the client device 1. This relies on step 140 being performed. id="p-73" id="p-73" id="p-73"

[0073] It is to be noted that a malicious coordinator device 3 cannot attack the encryption procedure provided herein. The temporary public key stored by the coordinator device 3 is signed by the static keypair of the field device 2, which is known a priori by the client device 1. Only the field device 2 can sign the entry and the client device 1 will not trust the entry unless it is correctly signed. So, temporary (ephemeral) encryption (forward and backward secrecy) is added without the need to also trust the coordinator device 3. id="p-74" id="p-74" id="p-74"

[0074] Fig 3 is a schematic diagram illustrating components of the client device 1, the field device 2 and the coordinator device 3 of Fig 1. While the scale of capacity and power requirements vary greatly between these devices, each one of these devices is a form of computer and can thus be described according to the following. A processor 60 is provided using any combination of one or more of a suitable central processing unit (CPU), graphics processing unit (GPU), multiprocessor, neural processing unit (NPU), microcontroller, digital signal processor (DSP), etc., capable of executing software instructions 67 stored in a memory 64, which can thus be a computer program product. The processor 60 could alternatively be implemented using an application specific integrated circuit (ASIC), field programmable gate array (FPGA), etc. The processor 60 can be configured to execute the method described with reference to Fig 2 above. id="p-75" id="p-75" id="p-75"

[0075] The memory 64 can be any combination of random-access memory (RAM) and/ or read-only memory (ROM). The memory 64 also comprises non-transitory persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid-state memory or even remotely mounted memory. id="p-76" id="p-76" id="p-76"

[0076] A data memory 66 is also provided for reading and/ or storing data during execution of software instructions in the processor 60. The data memory 66 can be any combination of RAM and/ or ROM. id="p-77" id="p-77" id="p-77"

[0077] An I/ O interface 62 is provided for communicating with external and/ or internal entities using communication suitable for the device. For the coordinator device 3 and the client device 1, this can be achieved using wired communication, e.g. based on Ethernet, and/ or wireless communication, e.g. Wi-Fi, and/ or a cellular network, complying with any one or a combination of sixth generation (6G) mobile networks, next generation mobile networks (fifth generation, 5G), LTE (Long Term Evolution), UMTS (Universal Mobile Telecommunications System) utilising W-CDMA (Wideband Code Division Multiplex), or any other current or future wireless network. For the client device 1 and the field device 2, the communication can be achieved using local communication, e.g. using Bluetooth, Bluetooth Low Energy (BLE), Wi-Fi, etc. id="p-78" id="p-78" id="p-78"

[0078] Other components are omitted in order not to obscure the concepts presented herein. id="p-79" id="p-79" id="p-79"

[0079] Fig 4 shows one example of a computer program product 90 comprising computer readable means. On this computer readable means, a computer program 91 can be stored in a non-transitory memory. The computer program can cause a processor to execute a method according to embodiments described herein. In this example, the computer program product is in the form of a removable solid-state memory, e.g. a Universal Serial Bus (USB) drive. As explained above, the computer program product could also be embodied in a memory of a device, such as the computer program product 64 of Fig 3. While the computer program 91 is here schematically shown as a section of the removable solid-state memory, the computer program can be stored in any way which is suitable for the computer program product, such as another type of removable solid-state memory, or an optical disc, such as a CD (compact disc), a DVD (digital versatile disc) or a Blu-Ray disc. 16 id="p-80" id="p-80" id="p-80"

[0080] The aspects of the present disclosure have mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims. Thus, while various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Claims

1. A method for enabling communication between a client device (1) and a field device (2), the method comprising: generating (40), by the field device (2), a temporary keypair comprising a temporary public key and a temporary private key; signing (41), by the field device, based on a long-term secret key forming part of a long-term keypair of the field device, a data item comprising the temporary public key, yielding a signature; sending (42), by the field device (2), a message comprising the data item and the signature to a coordinator device (3); obtaining (142), by the client device (1), the temporary public key for the field device (2) from the coordinator device (3); generating (144), by the client device (1), a request, which comprises encrypting the request based on the temporary public key for the field device (2); transmitting (146), by the client device (1), the request to the coordinator, for forwarding the request to the field device (2); receiving (43), by the field device (2), the request, originating from the client device (1); and decrypting (47), by the field device (2), the request using the temporary private key.

2. A method for enabling communication between a client device (1) and a field device (2), the method being performed in the field device (2), the method comprising: generating (40) a temporary keypair comprising a temporary public key and a temporary private key; signing (41), based on a long-term secret key forming part of a long-term keypair of the field device, a data item comprising the temporary public key, yielding a signature; sending (42) a message comprising the data item and the signature to a coordinator device (3); receiving (43) a request, originating from the client device (1); and decrypting (47) the request using the temporary private key.

3. The method according to claim 2, further comprising, after the receiving (46) a request: obtaining (44) a sequence indicator from the request; determining (45) the request to be invalid when the sequence indicator is the same as for a previously received request; and storing (46) a record of the sequence indicator in a data structure.

4. The method according to claim 3, wherein the data structure is a sequence of bits, wherein each bit corresponds to a single sequence indicator.

5. The method according to any one of claims 2 to 4, further comprising: performing (48) an action based on the decrypted request; and transmitting (50) a response message based on the result of the action.

6. The method according to claim 5, further comprising, prior to the transmitting a response (50): generating (49) a response based on the result of the action, which comprises encrypting the response based on a temporary public client key obtained from the decrypted request.

7. The method according to claim 6, wherein the step of generating (49) a response comprises including the message in the response and wherein the sending (42) of the message is performed by the transmitting (50) the response.

8. A field device for enabling communication between a client device (1) and the field device (2), the field device comprising: a processor (6o); and a memory (64) storing instructions (67) that, when executed by the processor, cause the field device (2) to: generate a temporary keypair comprising a temporary public key and a temporary private key; sign, based on a long-term secret key forming part of a long-term keypair of the field device, a data item comprising the temporary public key, yielding a signature; send a message comprising the data item and the signature to a coordinator device (3):receive a request, originating from the client device (1); and decrypt the request using the temporary private key.

9. A computer program (67, 91) for enabling communication between a client device (1) and the field device (2), the computer program comprising computer program code which, when executed on a field device (2) causes the field device (2) to: generate a temporary keypair comprising a temporary public key and a temporary private key; sign, based on a long-term secret key forming part of a long-term keypair of the field device, a data item comprising the temporary public key, yielding a signature; send a message comprising the data item and the signature to a coordinator device (3): receive a request, originating from the client device (1); and decrypt the request using the temporary private key.

10. A computer program product (64, 90) comprising a computer program according to claim 9 and a computer readable means comprising non-transitory memory in which the computer program is stored.

11. A method for enabling communication between a client device (1) and a field device (2), the method being performed in the client device (1), the method comprising: obtaining (142) a temporary public key for the field device (2) from a coordinator device (3); generating (144) a request, which comprises encrypting the request based on the temporary public key for the field device (2); and transmitting (146) the request to the coordinator, for forwarding the request to the field device (2).

12. The method according to claim 11, further comprising: obtaining (140) a temporary keypair for the client device (1), the temporary keypair comprising a temporary public key and a temporary secret key; wherein the generating (144) the request comprises including the temporary public key for the client device (1) in the request.

13. The method according to claim 12, further comprising: receiving (148) a response from the field device (2), routed via the coordinator device (3); decrypting (149) the response using the temporary secret key for the client device (1)- 15. A client device (1) for enabling communication between a client device (1) and a field device (2), the client device (1) comprising: a processor (6o); and a memory (64) storing instructions (67) that, when executed by the processor, cause the client device (1) to: obtain a temporary public key for the field device (2) from a coordinator device (3); generate a request, which comprises encrypting the request based on the temporary public key for the field device (2); and transmit the request to the coordinator, for forwarding the request to the field device (2).

14. A computer program (67, 91) for enabling communication between a client device (1) and a field device (2), the computer program comprising computer program code which, when executed on a client device (1) causes the client device (1) to: obtain a temporary public key for the field device (2) from a coordinator device (3); generate a request, which comprises encrypting the request based on the temporary public key for the field device (2); and transmit the request to the coordinator, for forwarding the request to the field device (2).

15. A computer program product (64, 90) comprising a computer program according to claim 14 and a computer readable means comprising non-transitory memory in which the computer program is stored.