SECURE SESSION

TECHNICAL FIELD

The present invention relates to an enhancement for a secure session established between a device for providing a service and a terminal, specifically between a Narrow-Band Intemet-of- Things (NB-IoT) device and an IoT server. The secure session is specifically one established according to the Datagram Transport Layer Security (DTLS) or Transport Layer Security (TLS) protocol. In particular, the present invention relates to a device for providing a service and to a terminal, which are able to re-establish the secure session in an improved manner. Further, the present invention relates to corresponding methods.

BACKGROUND

NB-IoT is a narrowband radio technology designed for the IoT. It focuses specifically on low cost, long battery life, and enabling a larger number of connected devices. In a typical NB-IoT application, an IoT device with a constrained resource (e.g. low power) wants and, to encrypt data on the one hand, and on the other hand wants at the same time to have a long battery life, even if there is very low battery capacity. Further, the IoT device wants to be guaranteed at least acceptable security, i.e. it typically requires authentication, integrity and confidentiality for client and server side.

A typical system for NB-IoT is shown in FIG. 8. The NB-IoT system includes typically three parties, namely an NB-IoT Device, an IoT platform, and an IoT server.

Conventionally, NB-IoT security depends on the DTLS/TLS protocols (which are more round handshake protocols). However, these DTLS/TLS protocols are rather complex handshake protocols. Further, Network Address Translation (NAT) typically changes frequently the IP address of the NB-IoT device. For this reason, the NB-IoT device needs to set up the DTLS/TLS secure session frequently, and thus has to frequently perform the complex DTLS/TLS handshake protocol (including several very expensive crypto operations, e.g. RSA-Decryption, Signature and exponential operations). This disadvantageously consumes a lot of power of the NB-IoT device, which leads to a short battery life.

A conventional solution proposed DTLS-resumption, in order to rebuild the DTLS-session. However, this solution still needs to perform a short-handshake DTLS protocol, which consumes a considerable amount of power of the NB-IoT device. At the same time, no privacy is provided for the client by this solution.

Another conventional solution proposed DTLS-extension using a connectID, in order to realize an efficient reuse of an identical DTLS/TLS session. However, this solution has to modify the original DTLS protocol. Further, the solution does not provide a concrete implementation for privacy.

SUMMARY

In view of the above-mentioned problems and disadvantages, the present invention aims at improving the existing solutions. The present invention has thereby the objective to overcome the problem of a terminal (like a NB-IoT device) that has to frequently perform the DTLS/TLS protocol. To this end, the present invention desires to provide a device and terminal for establishing a secure session, while the terminal consumes less power and thus has a longer battery life. No modifications to the DTLS/TLS protocol should be made by the solution. However, an efficient reuse of a DTLS/TLS session across different transport/intemet connections should be enabled. This reuse should be independent of parameters in the transport layer or lower. All of the above should be achieved with only a limited number of additional messages transmitted between terminal and device for providing a service.

The objective of the present invention is achieved by the solution provided in the enclosed independent claims. Advantageous implementations of the present invention are further defined in the dependent claims.

A first aspect provides a device for providing a service, the device being configured to establish a secure session with a terminal, thereby obtaining a master key and a session key, generate an identifier for the session, store an association of the identifier, the master key and the session key, and provide the identifier to the terminal. By storing the association identifier, master key, and session key, for instance, in a table or database, the device of the first aspect can quickly determine relevant information for re- establishing the secure session. Thus, the terminal does not have to establish the session each time anew, which saves battery power. Further, the identifier transmitted to the terminal requires only very little information overhead.

In an implementation form of the first aspect, the device is configured to receive an encrypted message from the terminal together with the identifier, obtain the session key based on the identifier from the stored association, and decrypt the message based on the obtained session key.

In this way, the device of the first aspect can quickly obtain the relevant information for decrypting the message. The terminal can in principle use the identifier and session key several times to messages, without the need to perform an additional establishment of the secure session.

In the further implementation form of the first aspect, the device is configured to generate the identifier for the session based on the master key and a random number.

Thus, the identifier is randomized and more secure.

In a further implementation form of the first aspect, the device is configured to encrypt the identifier based on the session key and the random number, before providing it to the terminal.

This makes the procedure carried out between terminal and device of the first aspect more secure.

In a further implementation form of the first aspect, the devices further configured to, after the secure session with the terminal ended, receive a request including the identifier from the terminal, and reestablish the secure session with the terminal based on the identifier in the request and the stored association.

In this way, the session can be reestablished without the need to establish it anew. Reestablishing a secure session means establishing the secure session without a handshake. This can be realized particularly because of the stored association. Thus, the terminal has a lower power consumption and longer battery life.

In a further implementation form of the first aspect, the request received from the terminal includes an identifier update request, and the device is configured to generate a new session key and a new identifier for the session, and provide the new identifier and new session key to the terminal.

Generating the new session key and identifier prevents that the terminal is easily tracked, which it would be used if fixed identifier.

In a further implementation form of the first aspect, the device is configured to generate the new session key based on the identifier in the request and the master key obtained based on this identifier from the stored association, and generate the new identifier based on the new session key.

This way the exchange is more secure.

In a further implementation form of the first aspect, the secure session is a session established based on the DTLS and/or TLS, protocol.

The protocol for establishing the secure session is performed only once between terminal and device, and the session can be re-established any time as described above. Thus the power consumption of the terminal is significantly reduced.

In a further implementation form of the first aspect, the device comprises a compiler configured to generate the identifier for the session.

The compiler allows using an original DTLS/TLS protocol for establishing the secure session. The protocol does not have to be changed, and the key exchange, identifier generation, and session re-establishment is implemented by means of the compiler. The compiler may run on a dedicated processing circuitry of the device. The compiler particularly takes the outcome of the DTLS/TLS protocol, i.e. the master key and session key, and builds thereon the key exchange protocol, and the identifier generation, without interfering in the DTLS/TLS handshake procedure.

A second aspect provides a terminal configured to establish a secure session with a device for providing a service, thereby obtaining a master key and a session key, receive an identifier for the session from the device, and send a message encrypted based on the session key together with the identifier to the device.

By using the identifier, the terminal can send messages multiple times to the device, without the need to re-establish the secure session. Thus its power consumption is significantly reduced.

In an implementation form of the second aspect, the identifier for the session is encrypted, and the terminal is configured to decrypt the identifier based on the session key, and/or verify the identifier based on the master key.

Thus, the procedure is made more secure.

In a further implementation form of the second aspect, the terminal is configured to after the secure session with the device ended, send a request including the identifier to the device, in order to reestablish the secure session.

Accordingly, the terminal can use the identifier to re-establish the secure session without requiring a new establishment of such session. This increase is largely its battery life.

In a further implementation form of the second aspect, the request sent to the device includes an identifier update request, and the terminal is configured to receive a new session key and a new identifier for the session from the device, and send a message encrypted based on the new session key together with the new identifier to the device.

This prevents that the terminal easily tracked. An attacker cannot easily locate and distinguish terminals, as it could if a fixed identifier was used.

A third aspect provides a method for a device for providing a service, the method comprising establishing a secure session with a terminal, thereby obtaining a master key and a session key, generating an identifier for the session, storing an association of the identifier, the master key and the session key, and providing the identifier to the terminal.

In an implementation form of the third aspect, the method comprises receiving an encrypted message from the terminal together with the identifier, obtaining the session key based on the identifier from the stored association, and decrypting the message based on the obtained session key.

In the further implementation form of the third aspect, the method comprises generating the identifier for the session based on the master key and a random number.

In a further implementation form of the third aspect, the method comprises encrypting the identifier based on the session key and the random number, before providing it to the terminal.

In a further implementation form of the third aspect, the method comprises, after the secure session with the terminal ended, receiving a request including the identifier from the terminal, and reestablishing the secure session with the terminal based on the identifier in the request and the stored association.

In a further implementation form of the third aspect, the request received from the terminal includes an identifier update request, and the method comprises generating a new session key and a new identifier for the session, and providing the new identifier and new session key to the terminal.

In a further implementation form of the third aspect, the method comprises generating the new session key based on the identifier in the request and the master key obtained based on this identifier from the stored association, and generating the new identifier based on the new session key.

In a further implementation form of the third aspect, the secure session is a session established based on the DTLS and/or TLS, protocol.

In a further implementation form of the third aspect, the method comprises generating the identifier for the session with a compiler. The method of the third aspect and implementation forms achieve all advantages and effects of the device of the first aspect and its respective implementation forms.

A fourth aspect provides a method for a terminal, comprising establishing a secure session with a device for providing a service, thereby obtaining a master key and a session key, receiving an identifier for the session from the device, and sending a message encrypted based on the session key together with the identifier to the device.

In an implementation form of the fourth aspect, the identifier for the session is encrypted, and the method comprises decrypting the identifier based on the session key, and/or verifying the identifier based on the master key.

In a further implementation form of the fourth aspect, the method comprises after the secure session with the device ended, sending a request including the identifier to the device, in order to reestablish the secure session.

In a further implementation form of the fourth aspect, the request sent to the device includes an identifier update request, and the method comprises receiving a new session key and a new identifier for the session from the device, and sending a message encrypted based on the new session key together with the new identifier to the device.

The method of the fourth aspect and its implementation forms achieve all advantages and effects of the terminal of the second aspect and its respective implementation forms.

In general, the solution presented in this disclosure proposes utilizing a key derivation function (KDF) and optionally a compiler to the original DTLS/TLS protocol, in order to implement a reuse of a DTLS-secure session for resolving the above-described NB-IoT device NAT problem. Specifically, the solution of the present invention does not need to modify the original DTLS/TLS protocol. Moreover, the solution of the present invention achieves client-side privacy. A fifth aspect provides a computer program product including computer executable instructions that, when executed by a processor, perform the steps of the methods of the third and fourth aspects and implementations thereof.

In comparison with conventional solutions, more efficient cryptographic primitives are used, namely a symmetric key derivation function, and an authenticated encryption scheme. The solution can be implemented by the use of only a modular compiler as a building block. For instance, an implementation may be with HMAC and/or Advanced Encryption Standard (AES) as a concrete and practical instance. Importantly, the solution provides enhanced privacy protection in the flavor of forward secrecy, and does not modify the underlying DTLS/TLS protocol.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 shows a device according to an embodiment of the present invention.

FIG. 2 shows a terminal according to an embodiment of the present invention. FIG. 3 shows a flowchart of a method performed by a device and a terminal according to embodiments of the present invention.

FIG. 4 shows a flowchart of a method performed by a device and a terminal according to embodiments of the present invention.

FIG. 5 illustrates generally a concept of the present invention.

FIG. 6 shows a method according to an embodiment of the present invention.

FIG. 7 shows a method according to an embodiment of the present invention.

FIG. 8 shows an overview over an IoT system.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 shows a device 100 according to an embodiment of the present invention. In particular, the device 100 is for providing a service to one or more terminals 110. For instance, the device 100 may be an IoT server (or service provider), and the terminal 110 may be an IoT device.

The device 100 is configured to, e.g. by means of one or more processors or other processing circuitry included in the device 100, to establish a secure session 101 with the terminal 110, thereby obtaining a master key 102 and a session key 103. The secure session 101 is particularly a session established based on the DTLS and/or TLS protocol.

Further, the device 100 is configured to generate an identifier 104 for the session 101, for example, based on the master key 102 and a random number. This may be done by a compiler of the device 100, which may run on one or more processors of the device 100. By using such a compiler, it can be ensured that the original protocol for establishing the secure session 101, e.g. DTLS/TLS protocol, is not modified.

Further, the device 100 is configured to store an association 105 of the identifier 104, the master key 102 and the session key 103. For instance, the device 100 may store a table or maintain a database, which include the identifier 104 associated with the master key 102 and the session key 103.

Further, the device 100 is configured to provide the identifier 104 to the terminal 110. Thereby, it may encrypt the identifier 104 based on the session key 103 and the random number, before providing it to the terminal 110.

FIG. 2 shows a terminal 200 according to an embodiment of the present invention. The terminal 200 may particularly be an IoT device (client), for example, an NB-IoT device. The terminal 200 may be the terminal 110 shown in FIG. 1.

The terminal 200 is configured to establish a secure session 201 with a device 210 for providing a service, e.g. an IoT server, thereby obtaining a master key 202 and a session key 203. The device 210 may in this document be the same as the device 100 shown in FIG. 1. Accordingly, in this document the secure session 201 may be the secure session 101 described with respect to the device 100 of FIG. 1, and the master key 202 and session key 203 may be the master key 102 and session key 103 described above with respect to the device 100.

Further, the terminal 200 is configured to receive an identifier 204 for the session 201 from the device 210. The identifier 204 in this document may be the identifier 104 described for the device 100 shown in FIG. 1. Accordingly, the identifier 204 may be encrypted, e.g. like the identifier 104 described above, and in this case the terminal 200 may accordingly be configured to decrypt the identifier 204, e.g. based on the session key 203, and/or verify the identifier 204, e.g. based on the master key 202.

Further, the terminal 200 is configured to send a message 205 encrypted based on the session key 203 together with the identifier 204 to the device 210.

FIG. 3 shows a flowchart of an exemplary method performed between a device 100, which builds on the device 100 shown in FIG. 1, and a terminal 200, which builds on the terminal 200 shown in FIG. 2. In particular, the device 100 is here a NB-IoT service provider (server), and the terminal 200 is here a NB-IoT device. At block 300, the NB-IoT device 200 and the service provider 100 perform the original DTLS/TLS protocol to establish the secure session 101. Thereby, they compute, at block 301, the master key 102 (master_secret: ms) and session key 103 (KTLS). These keys are shared keys.

After completing the DTLS/TLS protocol, the IoT service provider 100 generates, at block 302, a random number R and computes a Reuse Session IDentifier (RSID) as the identifier 104. This identifier 104 is used to identify this session 101. In particular, RSID = PRF(ms, R || NB-IoT DevicelD || NB-IoTAppServiceProvider ||“Reuse Session IDentifier”).

At block 303, the service provider 100 encrypts the identifier 104 (RSID) and R with the DTLS/TLS session key 103 (KTL _S ). Then, at block 304, it sends the ciphertext CRSID resulting from said encryption to the NB-IoT device 200, wherein CRSID = AEAD(KTL _S , RSID || R), and wherein AEAD is Authenticated Encryption with Associated Data.

At block 305, the NB-IoT device 200 verifies the ciphertext CRSID using the session key 103 (KTLS). If correct, it decrypts CRSID and gets the identifier 104 (RSID) and the random number R, i.e., RSID || R= AEAD(KTLS, CRSID).

Then, at block 306, it verifies the identifier 104 (RSID). To this end, it uses the master key 103 and the random number (ms, R) and computes RSID’ = PRF(ms, R || NB-IoT DevicelD || NB- IoTAppServiceProvider ||“Reuse Session IDentifier”). Then, the IoT device 200 tests (RSID’, RSID), and if RSID = RSID’, it accepts. Otherwise, it rejects.

At block 307, the NB-IoT device 200 sends the message 205 (M) to the service provider 100 with the identifier 104 (RSID), namely C = Enc(Kr _L s, M), RSID.

At block 308, the service provider 100 gets the identifier 104 (RSID) and uses it to find out the corresponding session key 103 (KTLS) from the stored association 105 (e.g. table or database). Then, it can verify and decrypt the ciphertext C.

As shown at block 309, the NB-IoT device 200 can use the identifier 104 and session key 103 (RSID and KTLS ) multiple times to encrypt and send one or more further messages. For achieving privacy property, the identifier 104 (RSID) may not be not fixed. The reason for this is, that a terminal 200 may be easily tracked when using a fixed identifier 104. This means that an attacker can locate and distinguish a certain terminal 200 by checking the changeless identifier 104 in the changed messages 205 between the terminal 200 and the server device 100. Thus, the identifier 104 may be refreshed periodically.

That is, refreshing the identifier 104 is beneficial to avoid a privacy risk of the terminal 200. For this purpose, the solution of the present invention introduces three new messages for achieving an identifier reffeshing/updating process. Namely, “updating_RSID_Request”, “serverRSIDUpdate”, and“updateRSIDAck”. The use of these messages is illustrated with respect to FIG. 4.

FIG. 4 shows particularly a flowchart of an exemplary method performed between a terminal 200, which builds on the terminal 200 shown in FIG. 2, particularly an NB-IoT device, and a device 100 for providing a service, which builds on the device 100 shown in FIG. 1, particularly a NB-IoT service provider.

Block 400 shows that the terminal 200 is in possession of the master key 103 (ms), session key

103 (KTLS) and the identifier 104 (RSID). At block 401, the terminal 200 requests an identifier

104 (RSID) update by first sending the“updating RSID Request” message to the service provider 100.

The service provider 100 updates the session key 202 by KRSID = PRF (ms, Label ||CurrentRSID), where Label stands for a fixed string "KeyUpdateRSID". Then, the service provider 100 generates a new random RSID as new identifier 104, and computes, corresponding ciphertext, namely by Enc(K _R si _D ,CurrentConnectID||NewConnectID). At block 402 it sends this ciphertext as“serverRSIDUpdate” message to the terminal 200.

At block 403, the terminal 200 generates the“updateRSIDAck” message as follows. The terminal 200 decrypts and verifies the“serverRSIDUpdate” message. The terminal 200 updates the master key 102 (K RSID = PRF (ms, Label ||CurrentRSID), where Label stands for a fixed string "KeyUpdateRSID“). Then, it decrypts and verifies the“serverRSIDUpdate” message. If correct, the terminal 200 uses K RSID and computes Enc(K_RSID, NewRSID). Finally, it sends this as the“updateRSIDAck” message to the service provider 100. Then, at block 404, the terminal 200 may send (application) messages 205 with the new RSID.

FIG. 5 illustrates the concept that a compiler 500 can be used at the device 100 to achieve advantages of the present invention. In particular, the compiler 500 can build on the established secure DTLS/TLS session 101 with an authenticator and a key derivation function, in order to achieve an authenticated key exchange protocol with privacy for reuse of the secure session 101 without modifying the DTLS/TLS protocol.

FIG. 6 shows a method 600 for a device 100 for providing a service. The device 100 may be the one shown in FIG. 1. The method 600 comprises a step 601 of establishing a secure session 101 with a terminal 110, thereby obtaining a master key 102 and a session key 103, a step 602 of generating an identifier 104 for the session 101, a step 603 of storing an association 105 of the identifier 104, the master key 102 and the session key 103, and a step 604 of providing the identifier 104 to the terminal 110. The terminal 1 10 may be the one shown in FIG. 1 or the terminal 200 shown in FIG. 2.

FIG. 7 shows a method 700 for a terminal 200. The terminal 200 may be the one shown in FIG. 2. The method 700 comprises a step 701 of establishing a secure session 201 with a device 210 for providing a service, thereby obtaining a master key 202 and a session key 203, a step 702 of receiving an identifier 204 for the session 201 from the device 210, and a step 703 of sending a message encrypted based on the session key 203 together with the identifier 204 to the device 210. The device 210 may be the one shown in FIG. 2 or may be the device 100 shown in FIG. 1.

The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article“a” or“an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.