Patent Description:
Field devices relating to Internet of Things, IoT, or Industry <NUM> applications are typically very resource constrained and often not even equipped with a real-time clock, RTC, because of power, energy, and physical size constraints of the field device. An RTC is a clock device that keeps track of the current date and time. It is typically realized in the form of a battery-backed integrated circuit. If necessary, this time information is synchronized with device external components or time sources to adjust the time within a system to have a base notion of time. IoT devices must be regularly updated to prevent large-scale disasters if major vulnerabilities are found. This poses a serious problem about how to verify the time validity of digital certificates on all such devices, which are not equipped with an RTC and/or cannot synchronize the date and time information and/or cannot rely on its local time information (e.g. because of an attack the time information cannot be trusted). In fact, it is not possible to verify whether a digital certificate is still valid or has expired without the knowledge about current time. Thus, following typical security policies it is not possible to establish a server-side certificate-based authenticated (TLS-secured) connection to download software or firmware updates to be installed on a field device.

For example, assuming an IoT device without RTC and about to establish a secure connection with a remote server to retrieve critical updates, e.g. over the transport layer security, TLS, protocol, 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 about the current time.

In principle, it could retrieve the current time information from a time server, e.g. using the network time protocol, NTP. However, this connection with the time server must also be secured, e.g., over the TLS protocol, otherwise an attacker could send a falsified time information to the IoT device and let it accept expired certificates from the update servers. For doing that, it needs to authenticate the time server using a digital certificate, i.e., it must verify that the digital certificate provided by the time server is valid and has not expired. However, the IoT device does not know about the current time and can't authenticate the time server. This is a chicken-and-egg problem.

A known approach of mitigating the problem is to fix an initial time during manufacturing and store it into the IoT device to be used as starting point once the device boots. However, this way only a rough time estimation is provided, and it does not necessarily protect if a digital certificate has expired after this fixed initial time.

A similar approach of mitigating the problem is to estimate the current time by interpolating the time information from multiple time servers. However, this approach won't help much as the connections to the time servers can't be secured without knowledge about the current time - as explained above.

Another approach of mitigating the problem is to avoid digital certificates and e.g. share a secret key between each IoT device and a remote time server. There are different ways to implement this approach and all have major drawbacks:.

A further approach of bootstrapping time information is provided by Bootstrapping Remote Secure Key Infrastructures, BRSKI (IETF draft https://datatracker. org/ doc/draft-ietfanima-bootstrapping-keyinfra). The approach leverages the fact that an intelligent electronic device, IED, has manufacturer-installed device and root certificates. During the process of connecting to a remote infrastructure, the device provisionally accepts certificates and utilizes the validity time of the peer certificate to adjust its local clock. Further on, the device establishes a connection to a manufacturer provided server, to get a signed voucher containing the new domain certificate to accept the new domain as valid. Once the device gets the voucher with the signature, it can further adjust the local time based on the signature time in the voucher. In a next step the device applies for an operational certificate at a local certification authority, CA, and utilizes the issuing time as further adjustment information.

A further approach applied in Precision Time Protocol, PTP (IEEE 1588v2. <NUM>) utilizes Timed Efficient Stream Loss-Tolerant Authentication, TESLA (RFC <NUM>) to distribute time information. TESLA utilizes server generated hash chains to provide delayed authentication. After a certain number of messages, the server releases the utilized key for the integrity protection of these messages in clear, allowing field devices to verify the received information in a delayed manner. The anchor value of the hash chain is to be distributed in a secure (integrity protected) way, typically protected by a digital signature or a shared secret.

From the Server-Based Certificate Validation Protocol, SCVP (RFC <NUM>) it is known to delegate certification path construction and certification path validation to a server. This approach can be used if a field device has constrained local resources. Nevertheless, the connection to the SCVP server is likely to be secured using certificates as well and therefore also depends on a locally available, i.e., synchronized time information.

The approach of Online Certificate Status Protocol, OCSP, Stapling is known to allow a server to provide fresh revocation information about its certificate utilized in a connection establishment. The OCSP issuer is either the issuing CA or a delegate, which may be a trusted third party. As the OCSP response information is digitally signed by the OCSP responder, local / synchronized time information is also required to validate the OCSP response.

<CIT> introduces a trust provider using established relationships with a client device and a server of an e-commerce merchant or service provider to assure the identity of each to the other. The e-commerce merchant can request an encrypted token from the client. The client may use a trust-provider key to generate the encrypted token. The server then passes the token to the trust provider, who only accepts tokens from known, authenticated entities. Tue Trust provider then verifies the token and returns a response to the server. The response may include a client verification for use by the server and an encrypted server verification that is forwarded by the server to the client. In this fashion, both the server and client may be authenticated without prior knowledge of each other.

<CIT> introduces systems and methods for performing digital rights management. In one embodiment, a digital rights management engine is provided that evaluates license associated with protected content to determine if a requested access or other use of the content_ is authorized. In some embodiments, the licenses contain control programs that are executable by the digital rights management engine.

<CIT> introduces a first network node arranged to obtain a second certificate and a second authentication token from a second network node. An identity unit is arranged to obtain a second identifier from the second certificate. An identity-based shared key unit arranged to generate an identity-based shared key by applying a key establishment algorithm of the identity-based key pre-distribution scheme on the second identifier and the first local key material. An authentication unit is arranged to authenticate the second network node by cryptographically verifying that the second authentication token has been computed from at least the identity-based shared key.

In view of the above, there is a continued need in the art to address some of the above-identified shortcomings of the prior art. In particular, there is a continued need in the art for establishing secure communications between devices without having to rely on local time information but still utilizing certificates in the initialization of the communication connection.

These underlying objects of the invention are each solved by the methods and devices as defined by the independent claims. Preferred embodiments of the invention are set forth in the dependent claims.

According to a first aspect, a method of operating a server device for establishing secure communication with a client device is provided. The method comprises: Receiving a query from the client device for a proof of identity of the server device. The query is based on a challenge issued by the client device. The method further comprises: Prompting a trusted third party for the proof of identity of the server device, receiving a response from the trusted third party comprising the proof of identity of the server device, and sending a response to the query, the response being based on the challenge and being indicative of the proof of identity.

According to a second aspect, a method of operating a client device for establishing secure communication with a server device is provided. The method comprises: Sending a query to the server device for a proof of identity of the server device 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 being based on the challenge and being indicative of the proof of identity, and verifying an identity of the server device using the response.

The method may further comprise: upon successful verification of the identity of the server device, inquiring an absolute time reference from the server device.

The verifying of the identity of the server device must not be based on the absolute time reference.

The challenge may have a limited period of validity, and the identity of the server device may selectively be verified in accordance with the limited period of validity.

The verifying comprises verifying a signature issued by the trusted third party using a private key of the trusted third party. The trusted third party may be a Certification Authority, CA.

The query comprises the challenge being 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 the trusted third party. The proof of identity of the server device may comprise the signature issued by the trusted third party using its private key. The signature may comprise the challenge being decrypted using the private key of the server device, and a public key of the server device. The response may comprise the proof of identity of the server device being 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 the trusted third party.

The method may further comprise prompting the trusted third party for the signed public key of the device.

According to a third aspect, a server device is arranged for establishing secure communication with a client device. The device comprises a processing unit being arranged for: Receiving a query from the client device for a proof of identity of the server device. The query is based on a challenge issued by the client device. The processing unit is further arranged for: Prompting a trusted third party for the proof of identity of the server device, receiving a response from the trusted third party comprising the proof of identity of the server device, and sending a response to the query. The response is based on the challenge and indicative of the proof of identity.

The processing unit of the server device may be arranged for performing the method of operating the server device for establishing secure communication with the client device according to various embodiments.

According to a fourth aspect, a client device is arranged for establishing secure communication with a server device. The device comprises a processing unit being arranged for: Sending a query to the server device for a proof of identity of the server device by a trusted third party. The query is based on a challenge issued by the client device. The processing unit is further arranged for: Receiving a response to the query being based on the challenge and being indicative of the proof of identity, and verifying an identity of the server device using the response.

The processing unit of the client device may be arranged for performing the method of operating the client device for establishing secure communication with the server device according to various embodiments.

The client device may be an Internet of Things, IoT, device.

Embodiments of the invention will be described with reference to the accompanying drawings, in which the same or similar reference numerals designate the same or similar elements.

"Secure communication" as used herein may refer to communication being prevented from being eavesdropped or intercepted by unauthorized parties, for example using methods of encryption.

A "query" and a "response" as used herein may refer to messages being exchanged between the client device and the server device, wherein the response is triggered by the query.

A "challenge" as used herein may refer to information provided by a challenging party to a challenged party in order to trigger a response that is indicative of the challenge, and indicative of a shared secret of the involved parties, or of similar knowledge. For instance, in case of RSA cryptography, the involved parties use asymmetric key pairs for ciphering, and in case of Elliptic Curve Digital Signature Algorithm, ECDSA, cryptography, the involved parties first conclude a key agreement, which in turn leads to a shared secret that is then used for ciphering. For instance, the challenge may be a random number (nonce), a shared secret may be a password merely known by the involved parties, and the response triggered by the challenge may be based on, i.e., inferred from, the nonce and the password and be encoded using a generally known algorithm. For instance, the challenge may be subjected to a cryptographic function, for example a Message Authentication Code, MAC, which may involve a key that is derived from the password. The challenging party may authenticate the challenged party with the challenging party by reproducing the very same encoding steps.

A "trusted third party" as used herein may refer to a third party facilitating interactions between two other parties who both have a trust relation to the third party.

A "certification authority", CA, as used herein may relate to a central authority in a context of public-key cryptography which acts as a trusted third party. A CA issues digital certificates which certify ownership of a public key by the named subject of the certificate. The certificate is also a confirmation or validation by the CA that the public key contained in the certificate belongs to the entity noted in the certificate. Other (relying) parties trusting the CA can verify the CA's signature to verify at the same time that a certain public key indeed belongs to whoever is identified in the certificate.

"Public key" and "secret key" as used herein may relate 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 identity of the user (e.g. the receiver's name).

A "private key generator", PKG, as used herein may relate to a central authority in a context of identity-based encryption which acts as a trusted third party. A PKG issues secret keys for decryption to every receiving entity, and therefore needs to be trusted by all receiving entities.

A "processing unit" as used herein may relate to a hardware entity of a computing device or a corresponding software entity that is arranged for execution of program instructions. Examples of processing units comprise microprocessors, microcontrollers, application-specific integrated circuits, ASICs, digital signal processors, virtual processors, processor emulations, and the like.

"Internet of Things", IoT, as used herein may relate to an extension of Internet connectivity into physical devices and everyday objects. This likely entails a low cost design of IoT devices only requiring a minimum of electronic resources. For instance, it may not be expected that every IoT device is equipped with a real-time clock, RTC.

<FIG> is a flow diagram illustrating a method of operating a server device for establishing secure communication with a client device, and a method of operating the client device for establishing secure communication with the server device according to embodiments and interacting with each other.

<FIG> is a schematic diagram illustrating the client device and the server device according to embodiments and interacting with each other and with a trusted third party.

Exemplary embodiments of the invention will now be described with reference to the drawings. While some embodiments will be described in the context of specific fields of application, the embodiments are not limited to this field of application. Further, the features of the various embodiments may be combined with each other unless specifically stated otherwise.

The drawings are to be regarded as being schematic representations, and elements illustrated in the drawings are not necessarily shown to scale.

<FIG> is a flow diagram illustrating a method <NUM> of operating a server device <NUM> for establishing secure communication with a client device <NUM>, and a method <NUM> of operating the client device <NUM> for establishing secure communication with the server device <NUM> according to embodiments and interacting with each other.

With reference to <FIG> (see method steps having bold lines), it will be appreciated that the methods <NUM>, <NUM> interact with each other in a basic form as follows:
At step <NUM>, the client device <NUM> sends a query M to the server device <NUM> for a proof of identity of the server device <NUM> by a trusted third party <NUM>. Correspondingly, at step <NUM>, the server device <NUM> receives the query M from the client device <NUM>. The query M is based on a challenge C issued <NUM> by the client device <NUM>.

At step <NUM>, the server device <NUM> prompts the trusted third party <NUM> for the proof of identity of the server device <NUM>.

At step <NUM>, the server device <NUM> receives a response from the trusted third party <NUM> comprising the proof of identity of the server device <NUM>.

At step <NUM>, the server device <NUM> sends a response R to the query M. Correspondingly, at step <NUM>, the client device <NUM> receives the response R. The response R is based on the challenge C and indicative of the proof of identity of the server device <NUM>.

At step <NUM>, the client device <NUM> verifies an identity of the server device <NUM> using the response R.

Advantageously, client devices <NUM> may authenticate remote server devices <NUM> without having local time information.

Advantageously, client devices <NUM> without an RTC may establish secure connections with remote server devices <NUM> (e.g. time and update servers).

Advantageously, client devices <NUM> equipped with an RTC may establish secure connections with remote server devices <NUM> if the RTC fails to (or is recognized not to) work correctly, as a back-up solution.

Advantageously, client devices <NUM> equipped with an RTC may perform synchronization / bootstrapping of local time information if the RTC is not battery powered to keep the time across device restarts or shutdowns.

Advantageously, no other client device <NUM> on the network is affected if the secret key of any client device <NUM> is compromised, since each client device <NUM> has its own key without the need of a complex key management like in the case of symmetric keys.

With continuing reference to <FIG>, the methods <NUM>, <NUM> may further comprise the following:
At step <NUM>, the client device <NUM> may inquire an absolute time reference from the server device <NUM> upon successful verification <NUM> of the identity of the server device <NUM>. The verifying of the identity of the server device <NUM> in the preceding step <NUM> is, however, not based on the absolute time reference.

The challenge C may have a limited period of validity, and the identity of the server device <NUM> may selectively be verified <NUM> in accordance with the limited period of validity.

Advantageously, the limited period of validity (a. "freshness") of the challenge C prevents replay attacks based on re-use of former appropriate responses R.

Still referring to <FIG>, in an embodiment drawing upon public key infrastructure, PKI, the generic methods <NUM>, <NUM> specified above may further be defined as follows:
The trusted third party <NUM> may be a Certification Authority, CA.

The respective client / server device <NUM>, <NUM> has a public key pkA, pkB and a private key skA, skB.

The respective public key pkA, pkB may be used either directly or indirectly for encryption.

At steps <NUM>, <NUM> the respective client / server device <NUM>, <NUM> may prompt the trusted third party <NUM>, i.e. the CA, for signing its public key pkA, pkB using the CA's private key skTTP:.

The server device <NUM> may share its public key pkB with the client device <NUM>, and the client device <NUM> may share its public key pkA with the server device <NUM>.

The private key skA, skB may be used for decryption.

The query M comprising the challenge C may be encrypted using the result of an operation based on the public key pkB of the server device <NUM>:
M ⇐ Enc( pkB, C).

The challenge C may be decrypted <NUM> from the query M using the private key skB of the server device <NUM>:
C ⇐ Dec( skB, M).

The proof of identity of the server device <NUM>, to which reference is made at steps <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>, may comprise, as part of the server device's certificate, a signature S issued by the trusted third party <NUM> using its private key skTTP. The signature S may comprise the challenge C and the public key pkB of the server device <NUM>:
S ⇐ Sign( skTTP, C||pkB).

The response R, to which reference is made at steps <NUM>, <NUM>, and <NUM>, may comprise the proof of identity of the server device <NUM>, i.e. the signature S, and may be encrypted using the result of an operation based on the public key pkA of the client device <NUM>:
R ⇐ Enc( pkA, S).

Conversely, the signature S may be decrypted from the response R by the client device <NUM> using the private key skA of the client device <NUM>:
S ⇐ Dec( skA, R).

At step <NUM>, the verifying may comprise verifying the signature S issued by the trusted third party <NUM> using a private key skTTP of the trusted third party <NUM>:
Verify( pkTTP, S) == True.

Advantageously, the embodiment works in conventional PKI infrastructures.

Still referring to <FIG>, in an alternative embodiment drawing upon identity-based encryption, IBE, the generic methods <NUM>, <NUM> specified above may further be defined as follows:
The trusted third party <NUM> may be a Private Key Generator, PKG.

The respective client / server device <NUM>, <NUM> has an identity idA, idB and a secret key kA, kB.

The respective identity idA, idB may be used for encryption.

The server device <NUM> may share its identity idB with the client device <NUM>, and the client device <NUM> may share its identity idB with the server device <NUM>.

The respective secret key kA, kB may be used for decryption.

At steps <NUM>, <NUM> the respective client / server device <NUM>, <NUM> may prompt the trusted third party <NUM>, i.e. the PKG, for its secret key kA, kB based on the identity idA, idB of the respective device <NUM>, <NUM>:.

Along with the respective secret keys kA, kB, further public parameters, PP, may be provided.

The query M comprising the challenge C may be encrypted using the identity idB of the server device <NUM> as well as a random identity idR issued by the client device <NUM>:
M ⇐ Enc( idB||idR, C, PP).

The client device <NUM> may share the random identity idR with the server device <NUM>.

The proof of identity of the server device <NUM>, to which reference is made at steps <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>, may comprise a secret key kBR issued by the trusted third party <NUM>. The secret key kBR is based on the identity idB of the server device <NUM> and the random identity idR:
kBR, PP ⇐ Issue( idB∥idR).

At step <NUM>, the challenge C may be decrypted using the proof of identity of the server device <NUM>, i.e. the secret key kBR of the trusted third party <NUM>:
C ⇐ Dec( kBR, M, PP).

The response R, to which reference is made at steps <NUM>, <NUM>, and <NUM>, may comprise the challenge C and may be encrypted using the identity idA of the client device <NUM>:
R ⇐ Enc( idA, C, PP).

At step <NUM>, the verifying may comprise verifying the challenge C using the secret key kA of the client device <NUM>: Dec(kA, R, PP) == C.

Advantageously, the embodiment also works in IBE or other types of infrastructures.

<FIG> is a schematic diagram illustrating the client device <NUM> and the server device <NUM> according to embodiments and interacting with each other and with a trusted third party <NUM>.

As shown in <FIG>, the respective client / server device <NUM>, <NUM> has a trust relation to the trusted third party <NUM>, as indicated by those arrows being identified with handshake symbols.

With reference to <FIG>, it will further be appreciated that the respective client / server device <NUM>, <NUM> arranged for establishing secure communication with the respective other device <NUM>, <NUM> comprises a respective processing unit <NUM>, <NUM>.

The processing unit <NUM> is arranged for sending <NUM> a query M to the server device <NUM> for a proof of identity of the server device <NUM> by a trusted third party <NUM>. Correspondingly, the processing unit <NUM> is arranged for receiving <NUM> the query M. The query M is based on a challenge C issued <NUM> by the client device <NUM>.

The processing unit <NUM> is further arranged for prompting <NUM> a trusted third party <NUM> for the proof of identity of the server device <NUM>, and for receiving <NUM> a response from the trusted third party <NUM> comprising the proof of identity of the server device <NUM>.

The processing unit <NUM> is further arranged for sending <NUM> a response R to the query M. Correspondingly, the processing unit <NUM> is further arranged for receiving <NUM> a response R to the query M. The response R is based on the challenge C and indicative of the proof of identity.

The processing unit <NUM> is further arranged for verifying <NUM> an identity of the server device <NUM> using the response R.

The respective processing units <NUM>, <NUM> may further be arranged for performing the respective methods <NUM>, <NUM> of operating the respective client / server device <NUM>, <NUM> for establishing secure communication with the respective other device <NUM>, <NUM> according to various embodiments.

Advantageously, the technical effects and advantages described above in relation with the methods <NUM>, <NUM> equally apply to the devices <NUM>, <NUM> having corresponding features.

The client device <NUM> may be an Internet of Things, IoT, device.

Claim 1:
A method (<NUM>) of operating a server device (<NUM>) for establishing secure communication with a client device (<NUM>), comprising
receiving (<NUM>) a query from the client device (<NUM>) for a proof of identity of the server device (<NUM>), the query being based on a challenge issued (<NUM>) by the client device (<NUM>);
prompting (<NUM>) a trusted third party (<NUM>) for the proof of identity of the server device (<NUM>);
receiving (<NUM>) a response from the trusted third party (<NUM>) comprising the proof of identity of the server device (<NUM>); and
sending (<NUM>) a response to the query , the response being based on the challenge and being indicative of the proof of identity
wherein the query comprising the challenge being encrypted using the result of an operation based on a public key of the server device (<NUM>), the public key of the server device (<NUM>) being signed by the trusted third party (<NUM>);
the proof of identity of the server device (<NUM>) comprising a signature issued by the trusted third party (<NUM>) using its private key, the signature comprising the challenge being decrypted (<NUM>) using the private key of the server device (<NUM>), and a public key of the server device (<NUM>);
the response comprising the proof of identity of the server device (<NUM>) being encrypted using the result of an operation based on a public key of the client device (<NUM>), the public key of the client device (<NUM>) being signed by the trusted third party (<NUM>).