Establishing secure communications without local time information

Abstract

A method (100; 300) and a device (10; 30) for establishing secure communication between devices (10; 30) without relying on local time information are provided. According to the method (100; 300), a client device (10) that is to establish secure communication with a server device (30) is provided with a certificate of its integrity by the server device (30). The certificate of the integrity of the server device (30) is issued by a trusted third party TTP, and both devices (10; 30) have a trust relationship with the trusted third party TTP.

Description

Technical Field

[0001] Various embodiments of the present invention are directed to methods and apparatus for establishing secure communications between devices without relying on local (ie, synchronized) time information. Background Art

[0002] Because of the power, energy and physical size constraints of field devices, field devices related to the Internet of Things IoT or Industry 4.0 applications are usually very resource-constrained and often not even equipped with a real-time clock RTC. RTC is a clock device that tracks the current date and time. It is usually implemented in the form of a battery-supported integrated circuit. If necessary, this time information is synchronized with an external device component or a time source to adjust the time within the system so as to have a basic time concept. IoT devices must be updated regularly to prevent large-scale disasters in the event of a major weakness. This causes a serious problem about how to verify the time validity of digital certificates on all such devices, which are not equipped with RTC and / or cannot synchronize date and time information and / or cannot rely on its local time information (for example, because of attacks, time information cannot be trusted). In fact, without knowing the current time, it is impossible to verify whether the digital certificate is still valid or expired. Therefore, according to typical security policies, it is impossible to establish a verification (TLS security) connection based on a server-side certificate to download software or firmware updates to be installed on the field device.

[0003] For example, assuming that the IoT device does not have an RTC and is about to establish a secure connection with a remote server, such as via the Transport Layer Security TLS protocol, to obtain critical updates, the IoT device needs to authenticate the remote server using a digital certificate, i.e., it must verify that the digital certificate provided by the remote server is valid and has not expired. However, the IoT device does not know the current time.

[0004] In principle, it can fetch the current time information from a time server, for example using the Network Time Protocol NTP. However, this connection to the time server must also be protected, for example via the TLS protocol, otherwise an attacker can send fake time information to the IoT device and make it accept an expired certificate from the update server. To do this, it needs to authenticate the time server using a digital certificate, i.e. it must check that the digital certificate provided by the time server is valid and has not expired. However, the IoT device does not know the current time and cannot authenticate the time server. This is a chicken and egg problem.

[0005] A known solution to mitigate this problem is to fix an initial time during manufacturing and store it in the IoT device to use as a starting point when the device boots up. However, in this way, only a rough time estimate is provided, and if the digital certificate has expired after this fixed initial time, it does not necessarily provide protection.

[0006] A similar solution to alleviate this problem is to estimate the current time by interpolating time information from multiple time servers. However, this solution will not help much because, as explained above, without knowing the current time, the connection with the time server cannot be protected.

[0007] Another solution to alleviate this problem is to avoid digital certificates and share a secret key between each IoT device and a remote time server, for example. There are different ways to implement this solution, and all have significant drawbacks:

[0008] a) All embedded IoT devices share the same secret key to communicate with the time server. However, if the secret key of any device is compromised, an attacker can send fake time information to all devices on the network. This can even be done from the compromised device itself.

[0009] b) Each device has its own secret key that is shared with the server. However, this is too expensive to manage in terms of key management and does not scale well if many IoT devices are deployed.

[0010] c) In any case, the use of a shared secret (symmetric key or password) either implies exemption from time-based credential revocation or implies replenishment of credentials with a maximum lifetime. In the first case, this is no better than using the certificate without checking time-based validity; in the latter case, reliable time information is also required for symmetric credentials.

[0011] d) Infrastructures that already rely on symmetric cryptography, using for example Kerberos and a centralized key distribution center KDC can leverage existing infrastructure and provide a single security association between the time server and the KDC, which can be used to issue tickets to clients to query the time from the time server. This obviously has the disadvantage of necessary support for Kerberos in field devices (but most importantly in the time server). Because they are distributed and used globally, association with a specific KDC is unlikely.

[0012] Another solution for booting time information is provided by the Bootstrapping Remote Security Key Infrastructure BRSKI (IETF https: / / datatracker.ietf.org / doc / draft-ietfanima-bootstrapping-keyinfra). This solution exploits the fact that intelligent electronic devices IED have device and root certificates installed by the manufacturer. During the process of connecting to the remote infrastructure, the device temporarily accepts the certificate and uses the validity time of the peer certificate to adjust its local clock. In addition, the device establishes a connection with a server provided by the manufacturer to obtain a signed voucher containing the new domain certificate to accept the new domain as valid. Once the device obtains a voucher with a signature, it can further adjust the local time based on the signature time in the voucher. In the next step, the device applies for an operational certificate at the local certification authority CA and uses the issuance time as further adjustment information.

[0013] Another solution implemented in the Precision Time Protocol PTP (IEEE 1588v2.1) uses Time Efficient Stream Loss Tolerant Authentication TESLA (RFC 4082) to distribute time information. TESLA uses a server-generated hash chain to provide delayed authentication. After a certain number of messages, the server releases the key used for integrity protection of these messages in the clear, allowing field devices to verify the received information in a delayed manner. The anchor value of the hash chain will be distributed in a secure (integrity-protected) manner, usually protected by a digital signature or shared secret.

[0014] From the server-based certificate validation protocol SCVP (RFC 5055), it is known to delegate the certification path construction and certification path validation to the server. This solution can be used if the field device has limited local resources. However, the connection to the SCVP server may also be protected using certificates and therefore also depends on locally available (i.e., synchronized) time information.

[0015] A scheme known as Online Certificate Status Protocol OCSP stapling allows a server to provide new revocation information about the certificate it used in connection establishment. An OCSP issuer is an issuing CA or a representative, which may be a trusted third party. Because the OCSP response information is digitally signed by the OCSP responder, local / synchronized time information is also required to confirm the OCSP response. Summary of the invention

[0016] In view of the above, there is a continuing need in the art to address some of the above-mentioned shortcomings of the prior art. In particular, there is a continuing need in the art to establish secure communications between devices without having to rely on local time information but still using certificates in the initialization of the communication connection.

[0017] Each of these essential objects of the invention is solved by a method and an arrangement as defined in the independent claims. Preferred embodiments of the invention are set out in the dependent claims.

[0018] According to a first aspect, there is provided a method of operating a server device to establish secure communications with a client device. The method comprises: receiving a query for proof of identity of the server device from the client device. The query is based on a challenge issued by the client device. The method further comprises: prompting a trusted third party to provide proof of identity of the server device, receiving a response from the trusted third party including proof of identity of the server device, and sending a response to the query, the response being based on the challenge and indicating proof of identity.

[0019] According to a second aspect, there is provided a method of operating a client device to establish secure communications with a server device. The method comprises: sending a query to the server device for proof of the identity of the server device provided by a trusted third party. The query is based on a challenge issued by the client device. The method further comprises: receiving a response to the query, the response being based on the challenge and indicating proof of identity; and verifying the identity of the server device using the response.

[0020] The method may further comprise, upon successful verification of the identity of the server device, querying the server device for an absolute time reference.

[0021] The verification of the identity of the server device need not be based on an absolute time reference.

[0022] The challenge may have a limited validity period, and the identity of the server device may be selectively verified based on the limited validity period.

[0023] The verification may include verifying a signature issued by a trusted third party using a private key of the trusted third party. The trusted third party may be a certification authority CA.

[0024] The query may include a challenge encrypted using the result of an operation based on a public key of the server device, wherein the public key of the server device may be signed by a trusted third party. The proof of the identity of the server device may include a signature issued by the trusted third party using its private key. The signature may include the challenge decrypted using the private key of the server device and the public key of the server device. The response may include a proof of the identity of the server device encrypted using the result of an operation based on a public key of the client device, wherein the public key of the client device may be signed by a trusted third party.

[0025] The method may further include prompting a trusted third party to provide a signed public key of the device.

[0026] The verification may include a verification challenge using a secret key of the client device, and the trusted third party may be a private key generator PKG.

[0027] The query may include a challenge encrypted using the identity of the server device and a random identity issued by the client device. The proof of the identity of the server device may include a secret key issued by a trusted third party. The secret key may be based on the identity of the server device and the random identity. The response may include a challenge decrypted using the proof of the identity of the server device and encrypted using the identity of the client device.

[0028] The method may further include prompting the trusted third party to provide a secret key of the device based on the identity of the device.

[0029] According to a third aspect, a server device is arranged to establish secure communication with a client device. The device comprises a processing unit, the processing unit being arranged to: receive a query for proof of identity of the server device from the client device. The query is based on a challenge issued by the client device. The processing unit is further arranged to: prompt a trusted third party to provide proof of identity of the server device, receive a response from the trusted third party including proof of identity of the server device, and send a response to the query. The response is based on the challenge and indicates proof of identity.

[0030] The processing unit of the server device may be arranged to perform the method of operating the server device to establish secure communication with the client device according to various embodiments.

[0031] According to a fourth aspect, a client device is arranged to establish secure communication with a server device. The device comprises a processing unit, the processing unit being arranged to: send a query to the server device for proof of the identity of the server device provided by a trusted third party. The query is based on a challenge issued by the client device. The processing unit is further arranged to: receive a response to the query, the response being based on the challenge and indicating proof of identity; and verify the identity of the server device using the response.

[0032] The processing unit of the client device may be arranged to perform a method of operating the client device to establish secure communication with a server device according to various embodiments.

[0033] The client device may be an Internet of Things (IoT) device. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Embodiments of the present invention will be described with reference to the accompanying drawings, wherein the same or similar reference numerals designate the same or similar elements.

[0035] As used herein, "secure communications" may refer to communications that are protected from eavesdropping or interception by unauthorized parties, such as using encryption methods.

[0036] As used herein, "query" and "response" may refer to messages exchanged between a client device and a server device, where a response is triggered by a query.

[0037] As used herein, a "challenge" may represent information that is provided by the challenger to the challenged party in order to trigger a response indicating a challenge and indicating a shared secret or similar knowledge of the relevant party. For example, in the case of RSA cryptography, the relevant parties use an asymmetric key pair for encryption, and in the case of elliptic curve digital signature algorithm ECDSA cryptography, the relevant parties first reach a key agreement, which in turn leads to a shared secret that is subsequently used for encryption. For example, the challenge can be a random number (a non-repeating value (nonce)), the shared secret can be a password known only to the relevant party, and the response triggered by the challenge can be based on a non-repeating value and a password, that is, inferred from a non-repeating value and a password, and encoded using a commonly known algorithm. For example, the challenge may be subjected to a cryptographic function, such as a message authentication code MAC, which may involve a key derived from a password. The challenging party can verify the challenged party to the challenging party by reproducing exactly the same encoding steps.

[0038] As used herein, a "trusted third party" may refer to a third party that facilitates an interaction between two other parties that both have a trust relationship with the third party.

[0039] As used herein, "certification authority" CA may refer to a central authority that acts as a trusted third party in the context of public key cryptography. A CA issues digital certificates that prove ownership of a public key by the designated subject of the certificate. A certificate is also a confirmation or verification by the CA that the public key contained in the certificate belongs to the entity named in the certificate. Other (relying) parties that trust the CA can verify the CA's signature to simultaneously verify that a public key does indeed belong to anyone identified in the certificate.

[0040] As used herein, "public key" and "secret key" may refer to a key pair used in identity-based encryption (a specific type of public key cryptography). The former is generally known and represents some unique information about the user's identity (e.g., the recipient's name).

[0041] As used herein, a "private key generator" PKG may refer to a central authority that acts as a trusted third party in the context of identity-based encryption. The PKG issues a secret key for decryption to each receiving entity and therefore needs to be trusted by all receiving entities.

[0042] As used herein, a "processing unit" may refer to a hardware entity or a corresponding software entity of a computing device arranged to execute program instructions. Examples of processing units include microprocessors, microcontrollers, application specific integrated circuits ASICs, digital signal processors, virtual processors, processor emulations, etc.

[0043] As used herein, the "Internet of Things" IoT may involve the extension of Internet connectivity into physical devices and everyday objects. This may entail low-cost designs of IoT devices that require only minimal electronic resources. For example, it may not be desirable for each IoT device to be equipped with a real-time clock RTC.

[0044] Figure 1 is a flowchart illustrating a method of operating a server device to establish secure communication with a client device and a method of operating a client device to establish secure communication with a server device according to an embodiment and interacting with each other.

[0045] Figure 2 is a schematic diagram illustrating a client device and a server device interacting with each other and with a trusted third party according to an embodiment. DETAILED DESCRIPTION

[0046] Exemplary embodiments of the present invention will now be described with reference to the accompanying drawings. Although some embodiments will be described in the context of a specific field of application, the embodiments are not limited to this field of application. In addition, unless specifically noted otherwise, the features of the various embodiments may be combined with each other.

[0047] The drawings should be regarded as schematic representations, and the elements shown in the drawings are not necessarily shown to scale. Instead, the various elements are represented so that their function and general purpose become clear to those skilled in the art.

[0048] Figure 1 is a flowchart illustrating a method 300 of operating a server device 30 to establish secure communication with a client device 10 and a method 100 of operating a client device 10 to establish secure communication with a server device 30 according to an embodiment and interacting with each other.

[0049] Reference Figure 1 (See method steps with bold lines), it will be appreciated that methods 100, 300 interact with each other in the following basic form:

[0050] At step 103, client device 10 sends query M to server device 30 for proof of identity of server device 30 provided by trusted third party 20. Accordingly, at step 303, server device 30 receives query M from client device 10. Query M is based on challenge C issued 102 by client device 10.

[0051] At step 305 , server device 30 prompts trusted third party 20 to provide proof of the identity of server device 30 .

[0052] At step 306 , server device 30 receives a response from trusted third party 20 that includes proof of the identity of server device 30 .

[0053] At step 308 , the server device 30 sends a response R to the query M. Accordingly, at step 108 , the client device 10 receives the response R. The response R is based on the challenge C and indicates proof of the identity of the server device 30 .

[0054] In step 109 , the client device 10 uses the response R to verify the identity of the server device 30 .

[0055] Beneficially, client device 10 may authenticate remote server device 30 without local time information.

[0056] Beneficially, a client device 10 without an RTC may establish a secure connection with a remote server device 30 (eg, a time and update server).

[0057] Beneficially, as a backup solution, if the RTC fails (or is identified as not) functioning properly, a client device 10 equipped with an RTC may establish a secure connection with a remote server device 30 .

[0058] Beneficially, a client device 10 equipped with an RTC may perform synchronization / bootstrapping of local time information if the RTC is not battery powered to maintain time during device reboot or shutdown.

[0059] Beneficially, if the secret key of any client device 10 is compromised, other client devices 10 on the network are not affected because each client device 10 has its own key without the need for complex key management as in the case of symmetric keys.

[0060] Continue to refer to Figure 1 , the method 100, 300 may further include the following steps:

[0061] In step 110, upon successful verification 109 of the identity of the server device 30, the client device 10 may query the server device 30 for an absolute time reference. However, the verification of the identity of the server device 30 in the previous step 109 is not based on an absolute time reference.

[0062] The challenge C may have a limited validity period, and the identity of the server device 30 may be selectively verified 109 based on the limited validity period.

[0063] Beneficially, the limited validity period (also called "freshness") of the challenge C prevents replay attacks based on reuse of a previously suitable response R.

[0064] Still refer to Figure 1 In an embodiment utilizing a public key infrastructure (PKI), the general methods 100, 300 specified above may be further defined as follows:

[0065] The trusted third party 20 may be a certification authority CA.

[0066] The respective client / server device 10, 30 has a public key pkA, pkB and a private key skA, skB.

[0067] The corresponding public keys pkA, pkB can be used directly or indirectly for encryption.

[0068] At steps 101, 301, the respective client / server device 10, 30 may prompt the trusted third party 20 (ie, CA) to sign its public key pkA, pkB using the CA's private key skTTP:

[0069]

[0070] Server device 30 may share its public key pkB with client device 10 , and client device 10 may share its public key pkA with server device 30 .

[0071] The private keys skA and skB can be used for decryption.

[0072] The query M including the challenge C may be encrypted using the result of an operation based on the public key pkB of the server device 30:

[0073]

[0074] Challenge C may be decrypted 304 from query M using private key skB of server device 30:

[0075]

[0076] The proof of the identity of the server device 30 mentioned in steps 103, 303, 305, 306, 308 and 108 may include a signature S issued by the trusted third party 20 using its private key skTTP as part of the server device's certificate. The signature S may include the challenge C and the public key pkB of the server device 30:

[0077]

[0078] The response R mentioned in steps 308, 108 and 109 may include proof of the identity of the server device 30, namely the signature S, and may be encrypted using the result of an operation based on the public key pkA of the client device 10:

[0079]

[0080] Conversely, signature S may be decrypted by client device 10 from response R using private key skA of client device 10:

[0081]

[0082] At step 109, the verification may include verifying the signature S issued by the trusted third party 20 using the private key skTTP of the trusted third party 20:

[0083]

[0084] Beneficially, this embodiment works within a traditional PKI infrastructure.

[0085] Still refer to Figure 1 In an alternative embodiment utilizing identity-based encryption (IBE), the general methods 100, 300 specified above may be further defined as follows:

[0086] The trusted third party 20 may be a private key generator PKG.

[0087] The respective client / server device 10, 30 has an identity idA, idB and a secret key skA, skB.

[0088] The corresponding identities idA, idB may be used for encryption.

[0089] The server device 30 may share its identity idB with the client device 10 , and the client device 10 may share its identity idB with the server device 30 .

[0090] The corresponding secret keys skA, skB can be used for decryption.

[0091] At steps 101, 301, the respective client / server device 10, 30 may prompt the trusted third party 20 (ie, PKG) to provide its secret key kA, kB based on the identity idA, idB of the respective device 10, 30:

[0092]

[0093] Together with the respective secret keys kA, kB, further public parameters PP may be provided.

[0094] The query M including the challenge C may be encrypted using the identity idB of the server device 30 and the random identity idR issued by the client device 10:

[0095]

[0096] The client device 10 may share the random identity idR with the server device 30 .

[0097] The proof of the identity of the server device 30 mentioned in steps 103, 303, 305, 306, 308 and 108 may include a secret key kBR issued by the trusted third party 20. The secret key kBR is based on the identity idB of the server device 30 and the random identity idR:

[0098]

[0099] At step 307, challenge C may be decrypted using proof of the identity of server device 30 (ie, the secret key kBR of trusted third party 20):

[0100]

[0101] The response R mentioned in steps 308, 108 and 109 may include the challenge C and may be encrypted using the identity idA of the client device 10:

[0102]

[0103] At step 109, the checking may include checking the challenge C using the secret key kA of the client device 10:

[0104]

[0105] Advantageously, this embodiment also works in an IBE or other type of infrastructure.

[0106] Figure 2 is a schematic diagram illustrating a client device 10 and a server device 30 interacting with each other and with a trusted third party 20 according to an embodiment.

[0107] like Figure 2 As shown in , the respective client / server devices 10, 30 have a trust relationship with a trusted third party 20, as indicated by those arrows identified with a handshake symbol.

[0108] Reference Figure 2 It will be further appreciated that the respective client / server device 10,30 arranged for establishing secure communications with the respective other device 30,10 comprises a respective processing unit 11,31.

[0109] The processing unit 11 is arranged for sending 103 a query M to the server device 30 for proof of the identity of the server device 30 provided by the trusted third party 20 . Accordingly, the processing unit 31 is arranged for receiving 303 the query M. The query M is based on a challenge C issued 102 by the client device 10 .

[0110] The processing unit 31 is further arranged for prompting 305 the trusted third party 20 to provide proof of the identity of the server device 30 and for receiving 306 a response from the trusted third party 20 comprising the proof of the identity of the server device 30 .

[0111] The processing unit 31 is further arranged for sending 308 a response R to the query M. Accordingly, the processing unit 11 is further arranged for receiving 108 a response R to the query M. The response R is based on the challenge C and indicates proof of identity.

[0112] The processing unit 11 is further arranged for checking 109 the identity of the server device 30 using the response R.

[0113] The respective processing unit 11, 31 may further be arranged for performing a respective method 100, 300 of operating the respective client / server device 10, 30 to establish a secure communication with the respective other device 30, 10 according to various embodiments.

[0114] Advantageously, the technical effects and advantages described above with respect to the methods 100 , 300 are also applicable to the devices 10 , 30 having corresponding features.

[0115] The client device 10 may be an Internet of Things (IoT) device.

[0116] Although methods and apparatus according to various embodiments have been described, the invention may, of course, be carried out in other ways than those specifically set forth herein without departing from the general inventive concept.

[0117] The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.

Claims

1. A method (300) of operating a server device (30) to establish secure communications with a client device (10), comprising: receiving a query (M) for proof of identity of a server device (30) from a client device (10), the query (M) being based on a challenge (C) issued (102) by the client device (10); prompting (305) the trusted third party (20) to provide proof of the identity of the server device (30); receiving (306) a response from the trusted third party (20) including proof of the identity of the server device (30); and sending (308) a response (R) to the query (M), the response (R) being based on the challenge (C) and indicating proof of identity, wherein the query (M) comprises the challenge (C) encrypted using the result of an operation based on a public key (pkB) of the server device (30), the public key (pkB) of the server device (30) being signed by the trusted third party (20); wherein the proof of the identity of the server device (30) comprises a signature (S) issued by the trusted third party (20) using its private key (skTTP), the signature (S) comprising a challenge (C) decrypted (304) using the private key (skB) of the server device (30) and a public key (pkB) of the server device (30); The response (R) includes proof of the identity of the server device (30) encrypted using the result of an operation based on the public key (pkA) of the client device (10), the public key (pkA) of the client device (10) being signed by a trusted third party (20).

2. A method (100) of operating a client device (10) to establish secure communications with a server device (30), comprising: sending (103) a query (M) to a server device (30) for proof of the identity of the server device (30) provided by a trusted third party (20), the query (M) being based on a challenge (C) issued (102) by a client device (10); receiving (108) a response (R) to the query (M), the response (R) being based on the challenge (C) and indicating proof of identity; and verifying (109) the identity of the server device (30) using the response (R), the verification (109) comprising verifying a signature (S) issued by the trusted third party (20) using a private key (skTTP) of the trusted third party (20); and The trusted third party (20) is the certification authority CA. wherein the query (M) comprises a challenge (C) encrypted using the result of an operation based on a public key (pkB) of the server device (30), the public key (pkB) of the server device (30) being signed by a trusted third party (20); wherein the proof of the identity of the server device (30) comprises a signature (S) issued by the trusted third party (20) using its private key (skTTP), the signature (S) comprising a challenge (C) decrypted (304) using the private key (skB) of the server device (30) and a public key (pkB) of the server device (30); The response (R) includes proof of the identity of the server device (30) encrypted using the result of an operation based on the public key (pkA) of the client device (10), the public key (pkA) of the client device (10) being signed by a trusted third party (20).

3. The method (100) of claim 2, further comprising: Upon successful verification (109) of the identity of the server device (30), the server device (30) is queried for an absolute time reference.

4. The method (100) as claimed in claim 3, The verification of the identity of the server device (30) is not based on an absolute time reference.

5. The method (100) according to any one of claims 2 to 4, The challenge (C) has a limited validity period, and The identity of the server device (30) is optionally verified (109) based on a limited validity period.

6. The method (100; 300) of claim 2, further comprising: Prompt (101; 301) a trusted third party (20) to provide a device (10; 30)’s signature public key (pkA, pkB).

7. The method (100) according to any one of claims 2 to 4, The checking (109) includes checking the challenge (C) using a secret key (kA) of the client device (10); and The trusted third party (20) is a private key generator PKG.

8. A method (100; 300) as claimed in any one of claims 2 to 4, the query (M) comprising a challenge (C) encrypted using an identity (idB) of the server device (30) and a random identity (idR) issued (102) by the client device (10); The proof of the identity of the server device (30) includes a secret key (kBR) issued by a trusted third party (20), the secret key (kBR) being based on the identity (idB) of the server device (30) and the random identity (idR); The response (R) includes a challenge (C) decrypted (307) using the proof of the identity of the server device (30) and encrypted using the identity (idA) of the client device (10).

9. The method of claim 7, further comprising: A trusted third party (20) is prompted (101; 301) to provide a secret key (kA, kB) of a device (10; 30) based on an identity (idA, idB) of the device (10; 30).

10. A server device (30) arranged to establish secure communication with a client device (10), comprising: A processing unit (31) is arranged to: receiving a query (M) for proof of identity of a server device (30) from a client device (10), the query (M) being based on a challenge (C) issued (102) by the client device (10); prompting (305) the trusted third party (20) to provide proof of the identity of the server device (30); receiving (306) a response from the trusted third party (20) including proof of the identity of the server device (30); and sending (308) a response (R) to the query (M), the response (R) being based on the challenge (C) and indicating proof of identity, wherein the query (M) comprises the challenge (C) encrypted using the result of an operation based on a public key (pkB) of the server device (30), the public key (pkB) of the server device (30) being signed by the trusted third party (20); wherein the proof of the identity of the server device (30) comprises a signature (S) issued by the trusted third party (20) using its private key (skTTP), the signature (S) comprising a challenge (C) decrypted (304) using the private key (skB) of the server device (30) and a public key (pkB) of the server device (30); The response (R) includes proof of the identity of the server device (30) encrypted using the result of an operation based on the public key (pkA) of the client device (10), the public key (pkA) of the client device (10) being signed by a trusted third party (20).

11. A client device (10) arranged to establish secure communications with a server device (30), comprising: A processing unit (11) is arranged to: sending (103) a query (M) to a server device (30) for proof of the identity of the server device (30) provided by a trusted third party (20), the query (M) being based on a challenge (C) issued by a client device (10); receiving (108) a response (R) to the query (M), the response (R) being based on the challenge (C) and indicating proof of identity; and verifying (109) the identity of the server device (30) using the response (R), the verification (109) comprising verifying a signature (S) issued by the trusted third party (20) using a private key (skTTP) of the trusted third party (20); and The trusted third party (20) is the certification authority CA. wherein the query (M) comprises a challenge (C) encrypted using the result of an operation based on a public key (pkB) of the server device (30), the public key (pkB) of the server device (30) being signed by a trusted third party (20); wherein the proof of the identity of the server device (30) comprises a signature (S) issued by the trusted third party (20) using its private key (skTTP), the signature (S) comprising a challenge (C) decrypted (304) using the private key (skB) of the server device (30) and a public key (pkB) of the server device (30); The response (R) includes proof of the identity of the server device (30) encrypted using the result of an operation based on the public key (pkA) of the client device (10), the public key (pkA) of the client device (10) being signed by a trusted third party (20).

12. The client device (10) according to claim 11, The processing unit (11) is arranged for performing a method (100) as claimed in any one of the preceding claims 3-9.

Images