WO2022131387A1

WO2022131387A1 - Communication device, authentication server, and methods for authentication

Info

Publication number: WO2022131387A1
Application number: PCT/KR2020/018302
Authority: WO
Inventors: Jung Hoon Kim; Iro CHAE; Jong Ahn Lee; Nam Hyeok KWAG
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2020-12-15
Filing date: 2020-12-15
Publication date: 2022-06-23

Abstract

The present disclosure is related to a communication device, an authentication server, and methods for authentication. The method at a communication device for authentication comprises: receiving, from an authentication server, a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device; and transmitting, to the authentication server, a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data, in response to the request message.

Description

COMMUNICATION DEVICE, AUTHENTICATION SERVER, AND METHODS FOR AUTHENTICATION

The present disclosure is related to the field of authentication, and in particular, to a communication device, an authentication server, and methods for authentication.

The Internet of Things (IoT) is a network of physical objects, such as vehicles, machines, pipeline sensors, home appliances, that use sensors and Application Programming Interfaces (APIs) to connect and exchange data over the Internet. The IoT depends on a whole host of technologies, such as APIs that connect devices to the Internet. Other key IoT technologies may include Big Data management tools, predictive analytics, Artificial Intelligence (AI) and machine learning, the cloud, and radio communication, etc.

Whether it is a sensor-based device or used to perform a specific function, all IoT devices are open to hacking unless preventative measures are taken. There are several examples of security risks, from disabling a surveillance monitor on a Turkish pipeline to attacks on medical devices such as insulin pumps and magnetic resonance imaging (MRI) machines. These attacks are potentially life-threatening and indicate that some hackers have no scruples when it comes to target selection or gaining bragging rights to fellow cybercriminals. Clearly, connected IoT devices incorporate risks that could endanger lives or jeopardize the wellbeing of companies or families.

However, many of these devices were designed without taking security into full consideration. Internet-connected devices deserve special consideration with malicious attack, but unlike personal computers (PCs) or smartphones, IoT devices are generally short on processing power and memory. This means that IoT devices lack security solutions and encryption protocols that would protect them from threats.

Therefore, authentication is one of the major security issues for the point that weak authentication can lead to attacks. A lot of malware attacks can exploit the username and password, especially if the user does not change his/her password more frequently or just uses the default. Some threats may come from the linked devices. If the authentication scheme is compromised, it could lead to unauthorized access to other smart objects and then they will become threats. A proper authentication scheme, on the other hand, can prevent these attacks on IoT devices by ensuring the validity of peers' identities prior to the communication.

According to a first aspect of the present disclosure, a method at a communication device for authentication is provided. The method comprises: receiving, from an authentication server, a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device; and transmitting, to the authentication server, a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data, in response to the request message. With the method according to this embodiment, an authentication mechanism which does not require data encryption is provided, and therefore it is much simpler than existing security solutions such as IP-SEC, Pre-shared key using SSH, etc. Further, the mechanism does not have to manage ID and password for IoT devices, and it can be used in many different applications comprising smart home, smart factory, smart grid, even to a smart city.

In some embodiments, the method may further comprise: receiving, from the authentication server, an authentication result message indicating whether the communication device is successfully authenticated by the authentication server or not. In some embodiments, each of the multiple pieces of data is a piece of time-varying data. In some embodiments, each of the multiple pieces of data may have at least one type of: time-varying sensing data transmitted by the communication device; timestamp data transmitted and/or received by the communication device; time-varying login data transmitted by the communication device; time-varying log data transmitted by the communication device; and time-varying command data received at the communication device. In some embodiments, the multiple pieces of data may be stored at the communication device and each of the multiple pieces of data is assigned with an index, wherein the request message may comprise at least one index indicating the at least one piece of data. By authenticating with the time-varying data such as login information, command, sensing data, etc., a way of strong authentication and validation of IoT devices may be provided, which enables protecting IoT devices from unauthorized access and control. Therefore, this authentication mechanism does not require high computing power, which further helps low battery consumption of IoT devices.

In some embodiments, before receiving the request message, the method may further comprise negotiating, with the authentication server, at least one parameter of: a number of the multiple pieces of data to be stored at the communication device; a type of the multiple pieces of data to be stored at the communication device; a number of rounds for authentication; and whether communication between the communication device and the authentication server is to be encrypted or not. With these negotiated parameters, it is easy to control the security grade of authentication, for example, by requiring different security levels (e.g. different rounds of authentication, different types of data, or different numbers of pieces of data for authentication).

In some embodiments, the method may further comprise: adjusting the stored multiple pieces of data in response to transmitting and/or receiving a new piece of data of the negotiated type. In some embodiments, the multiple pieces of data may be stored in a First-In-First-Out (FIFO) queue. In some embodiments, the step of receiving a request message and the step of transmitting a response message may be performed as according to the negotiated number of rounds for authentication. In some embodiments, the method may further comprise: accessing one or more services and/or resources hosted in a secure zone via the authentication server in response to the authentication result message indicating successful authentication with the authentication server. In some embodiments, the method may further comprise: initiating a re-synchronization procedure with the authentication server to have the multiple pieces of data synchronized with the multiple pieces of data which are maintained by the authentication server in response to the authentication result message indicating failed authentication with the authentication server.

In some embodiments, a message exchanged between the communication device and the authentication server may be encrypted. With the encrypted messages, the security of the system may be further improved.

In some embodiments, the communication device may have a label that is configured to provide information for a registration procedure for the communication device. In some embodiments, the label may be a Quick Response (QR) code containing information for an automatic registration of the communication device. By using a QR code, it is much more convenient for a user to register its communication device without manually inputting all required information, and therefore improving user experience and reducing potential errors in registration.

In some embodiments, after negotiating, with the authentication server, at least one parameter and before receiving, from the authentication server, a request message, the method may further comprise: transmitting, to the authentication server, an authentication request message for requesting authentication of the communication device. In some embodiments, the method may further comprise: receiving, from the authentication server, a static request message for requesting static data which is preconfigured in the communication device; and transmitting, to the authentication server, a static response message comprising the required static data in response to the static request message. In some embodiments, the static data may comprise an identifier of the communication device. In some embodiments, the multiple pieces of data may be received from another communication device. With the static request/response messages, an initial authentication may be achieved even without any time-varying data, and therefore provides for a basic level of security.

In some embodiments, the method may further comprise: receiving, from another authentication server, another request message for requesting at least one of the multiple pieces of data; and transmitting, to the other authentication server, another response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data in response to the other request message. According to this embodiment, when roaming to another security zone, the communication device may be authenticated by another authentication server by using the previously stored data, and therefore the roaming scenario is supported.

In some embodiments, the data uniquely identifying the at least one piece of data may be a digital digest of the at least one piece of data. With the digital digest, any sensitive IoT data may be prevented from being transmitted through the network, and therefore the security of the authentication mechanism may be further improved.

According to a second aspect of the present disclosure, a communication device is provided. The communication device comprises: a processor; a memory storing instructions which, when executed by the processor, cause the processor to: receive, from an authentication server, a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device; and transmit, to the authentication server, a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data, in response to the request message. In some embodiments, the instructions, when executed by the processor, may further cause the processor to perform any method of the first aspect.

According to a third aspect of the present disclosure, a communication device is provided. The communication device is adapted to: receive, from an authentication server, a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device; and transmit, to the authentication server, a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data, in response to the request message. In some embodiments, the communication device may be further adapted to perform any method of the first aspect.

According to a fourth aspect of the present disclosure, a method at an authentication server for authentication is provided. The method comprises: transmitting, to a communication device, a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device and stored in a database which is accessible to the authentication server; receiving, from the communication device, a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data; and determining whether the communication device is successfully authenticated or not at least partially based on the response message. With the method according to this embodiment, an authentication mechanism which does not require data encryption is provided, and therefore it is much simpler than existing security solutions such as IP-SEC, Pre-shared key using SSH, etc. Further, the mechanism does not have to manage ID and password for IoT devices, and it can be used in many different applications comprising smart home, smart factory, smart grid, even to a smart city.

In some embodiments, the method may further comprise: transmitting, to the communication device, an authentication result message indicating whether the communication device is successfully authenticated or not based on the determination. In some embodiments, the step of determining whether the communication device is successfully authenticated or not may comprise: comparing the at least one piece of data comprised in the response message with corresponding at least one piece of data retrieved from the database, respectively; and determining the communication device is successfully authenticated or not in response to the result of comparison. In some embodiments, the step of determining whether the communication device is successfully authenticated or not may comprise: comparing the data comprised in the response message with data derived from at least one corresponding piece of data retrieved from the database in a same way in which the data comprised in the response message is derived, respectively; and determining the communication device is successfully authenticated or not in response to the result of comparison. In some embodiments, each of the multiple pieces of data may be a piece of time-varying data. In some embodiments, each of the multiple pieces of data may have at least one type of: time-varying sensing data transmitted by the communication device; timestamp data transmitted and/or received by the communication device; time-varying login data transmitted by the communication device; time-varying log data transmitted by the communication device; and time-varying command data received at the communication device. In some embodiments, the database may be hosted locally at or remote to the authentication server, and each of the multiple pieces of data is assigned with an index, wherein the request message may comprise at least one index indicating the at least one piece of data. By authenticating with the time-varying data such as login information, command, sensing data, etc., a way of strong authentication and validation of IoT devices may be provided, which enables protecting IoT devices from unauthorized access and control. Therefore, this authentication mechanism does not require high computing power, which further helps low battery consumption of IoT devices.

In some embodiments, before transmitting the request message, the method may further comprise negotiating, with the communication device, at least one parameter of: a number of the multiple pieces of data to be stored at the database; a type of the multiple pieces of data to be stored at the database; a number of rounds for authentication; and whether communication between the communication device and the authentication server is to be encrypted or not. With these negotiated parameters, it is easy to control the security grade of authentication, for example, by requiring different security levels (e.g. different rounds of authentication, different types of data, or different numbers of pieces of data for authentication).

In some embodiments, the method may further comprise: causing the database to adjust the multiple pieces of data in response to transmitting and/or receiving a new piece of data of the negotiated type to and/or from the communication device. In some embodiments, the multiple pieces of data may be stored in a First-In-First-Out (FIFO) queue. In some embodiments, the step of transmitting a request message, the step of receiving a response message, and the step of determining whether the communication device is successfully authenticated or not may be performed as according to the negotiated number of rounds for authentication. In some embodiments, the step of determining whether the communication device is successfully authenticated or not at least partially based on the response message may comprise: determining whether the communication device is successfully authenticated or not based on the response message and the one or more additional response messages.

In some embodiments, the method may further comprise: accessing one or more services and/or resources hosted in a secure zone on behalf of the communication device in response to the authentication result message indicating successful authentication. In some embodiments, the method may further comprise: performing a re-synchronization procedure with the communication device to cause the database to have the multiple pieces of data synchronized with those stored at the communication device in response to the authentication result message indicating failed authentication with the authentication server.

In some embodiments, before negotiating, with the communication device, at least one parameter, the method may further comprise: receiving a registration request for registering the communication device, the registration request comprising an identifier of the communication device; transmitting, to a device information database, a device information request for static data of the communication device, the device information request comprising the identifier of the communication device; and receiving the static data from the device information database. In some embodiments, after negotiating, with the communication device, at least one parameter and before transmitting, to the communication device, a request message, the method may further comprise: receiving, from the communication device, an authentication request message for requesting authentication of the communication device.

In some embodiments, the method may further comprise: transmitting, to the communication device, a static request message for requesting the static data; receiving, from the communication device, a static response message in response to the static request message; and determining whether the communication device is successfully authenticated or not based on the static response message. With the static request/response messages, an initial authentication may be achieved even without any time-varying data, and therefore provides for a basic level of security.

In some embodiments, the authentication server may be a node of a block chain network, and the multiple pieces of data are maintained and shared by the block chain network. In some embodiments, before the step of transmitting, to the communication device, the request message, the method may further comprise: retrieving, from the block chain network, the multiple pieces of data for the communication device. According to this embodiment, when the communication device is roaming to another security zone, the authentication server therein may retrieve the data for authentication from another authentication server via the blockchain technology, and therefore the roaming scenario is supported.

In some embodiments, the method may further comprise: starting a timer for the communication device in response to determining that the communication device is successfully authenticated; and determining that the authentication of the communication device is expired upon the expiration of the timer. In some embodiments, the method may further comprise: transmitting, to a second communication device, a second request message for requesting at least one of multiple pieces of second data, the multiple pieces of second data being communicated by the second communication device and stored in the database; receiving, from the second communication device, a second response message comprising the at least one piece of second data which is requested and/or data uniquely identifying the at least one piece of second data; and determining whether the second communication device is successfully authenticated or not at least partially based on the second response message.

According to a fifth aspect of the present disclosure, an authentication server is provided. The authentication server comprises: a processor; a memory storing instructions which, when executed by the processor, cause the processor to: transmit, to a communication device, a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device and stored in a database which is accessible to the authentication server; receive, from the communication device, a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data; and determine whether the communication device is successfully authenticated or not at least partially based on the response message. In some embodiments, the instructions, when executed by the processor, may further cause the processor to perform any method of the fourth aspect.

According to a sixth aspect of the present disclosure, an authentication server is provided. The authentication server is adapted to: transmit, to a communication device, a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device and stored in a database which is accessible to the authentication server; receive, from the communication device, a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data; and determine whether the communication device is successfully authenticated or not at least partially based on the response message. In some embodiments, the communication device may be further adapted to perform any method of the fourth aspect.

According to a seventh aspect of the present disclosure, a computer program comprising instructions is provided. The instructions, when executed by at least one processor, cause the at least one processor to carry out any method of the first aspect and/or the fourth aspect.

According to an eighth aspect of the present disclosure, a carrier containing the computer program of the seventh aspect is provided. The carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

According to a ninth aspect of the present disclosure, a system for authentication is provided. The system comprises: one or more communication devices of the second aspect and/or the third aspect; and at least one authentication server of the fifth aspect and/or the sixth aspect.

In addition to the advantages listed above, the mechanism according to some embodiments of the present disclosure is scalable, and therefore it is readily applicable to an IoT network comprising numerous IoT devices.

The foregoing and other features of the present disclosure will become more fully apparent from the following description and appended claims, taken in conjunction with the accompanying drawings. Understanding that these drawings depict only several embodiments in accordance with the disclosure and therefore are not to be considered limiting of its scope, the disclosure will be described with additional specificity and detail through use of the accompanying drawings.

Fig. 1 is an overview diagram illustrating an exemplary IoT network in which authentication for IoT devices according to an embodiment of the present disclosure is applicable.

Fig. 2 is a diagram illustrating an exemplary overall procedure for authenticating IoT devices according to an embodiment of the present disclosure.

Fig. 3 is a diagram illustrating exemplary procedures for registering an IoT device according to an embodiment of the present disclosure.

Fig. 4 is a diagram illustrating an exemplary procedure for authenticating an IoT device according to an embodiment of the present disclosure.

Fig. 5 is a diagram illustrating exemplary procedures for accessing a secure zone by an authenticated IoT device according to an embodiment of the present disclosure.

Fig. 6 is a diagram illustrating how time varying data is synchronized between IoT devices and an authentication server according to an embodiment of the present disclosure.

Fig. 7 is a diagram illustrating an exemplary scenario in which authentication for a roaming IoT device according to an embodiment of the present disclosure is applicable.

Fig. 8 is a flow chart illustrating an exemplary method at a communication device for authentication according to an embodiment of the present disclosure.

Fig. 9 is a flow chart illustrating an exemplary method at an authentication server for authentication according to an embodiment of the present disclosure.

Fig. 10 schematically shows an embodiment of an arrangement which may be used in a communication device or an authentication server according to an embodiment of the present disclosure.

Fig. 11 is a block diagram of an exemplary communication device according to an embodiment of the present disclosure.

Fig. 12 is a block diagram of an exemplary authentication server according to an embodiment of the present disclosure.

Hereinafter, the present disclosure is described with reference to embodiments shown in the attached drawings. However, it is to be understood that those descriptions are just provided for illustrative purpose, rather than limiting the present disclosure. Further, in the following, descriptions of known structures and techniques are omitted so as not to unnecessarily obscure the concept of the present disclosure.

Those skilled in the art will appreciate that the term "exemplary" is used herein to mean "illustrative," or "serving as an example," and is not intended to imply that a particular embodiment is preferred over another or that a particular feature is essential. Likewise, the terms "first", "second", "third", "fourth," and similar terms, are used simply to distinguish one particular instance of an item or feature from another, and do not indicate a particular order or arrangement, unless the context clearly indicates otherwise. Further, the term "step," as used herein, is meant to be synonymous with "operation" or "action." Any description herein of a sequence of steps does not imply that these operations must be carried out in a particular order, or even that these operations are carried out in any order at all, unless the context or the details of the described operation clearly indicates otherwise.

Conditional language used herein, such as "can," "might," "may," "e.g.," and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or states. Thus, such conditional language is not generally intended to imply that features, elements and/or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or states are included or are to be performed in any particular embodiment. Also, the term "or" is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term "or" means one, some, or all of the elements in the list. Further, the term "each," as used herein, in addition to having its ordinary meaning, can mean any subset of a set of elements to which the term "each" is applied.

The term "based on" is to be read as "based at least in part on." The term "one embodiment" and "an embodiment" are to be read as "at least one embodiment." The term "another embodiment" is to be read as "at least one other embodiment." Other definitions, explicit and implicit, may be included below. In addition, language such as the phrase "at least one of X, Y and Z," unless specifically stated otherwise, is to be understood with the context as used in general to convey that an item, term, etc. may be either X, Y, or Z, or a combination thereof.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limitation of example embodiments. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises", "comprising", "has", "having", "includes" and/or "including", when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/ or combinations thereof. It will be also understood that the terms "connect(s)," "connecting", "connected", etc. when used herein, just mean that there is an electrical or communicative connection between two elements and they can be connected either directly or indirectly, unless explicitly stated to the contrary.

Of course, the present disclosure may be carried out in other specific ways than those set forth herein without departing from the scope and essential characteristics of the disclosure. One or more of the specific processes discussed below may be carried out in any electronic device comprising one or more appropriately configured processing circuits, which may in some embodiments be embodied in one or more application-specific integrated circuits (ASICs). In some embodiments, these processing circuits may comprise one or more microprocessors, microcontrollers, and/or digital signal processors programmed with appropriate software and/or firmware to carry out one or more of the operations described above, or variants thereof. In some embodiments, these processing circuits may comprise customized hardware to carry out one or more of the functions described above. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Although multiple embodiments of the present disclosure will be illustrated in the accompanying Drawings and described in the following Detailed Description, it should be understood that the disclosure is not limited to the disclosed embodiments, but instead is also capable of numerous rearrangements, modifications, and substitutions without departing from the present disclosure that as will be set forth and defined within the claims.

Further, please note that although the following description of some embodiments of the present disclosure is given in the context of IoT, the present disclosure is not limited thereto. In fact, as long as authentication is involved, the inventive concept of the present disclosure may be applicable to any appropriate communication architecture, for example, to Wi-Fi, Bluetooth, Ethernet, Global System for Mobile Communications (GSM) / General Packet Radio Service (GPRS), Enhanced Data Rates for GSM Evolution (EDGE), Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), Time Division - Synchronous CDMA (TD-SCDMA), CDMA2000, Worldwide Interoperability for Microwave Access (WiMAX), Wireless Fidelity (Wi-Fi), 4th Generation Long Term Evolution (LTE), LTE-Advance (LTE-A), or 5th Generation New Radio (5G NR), etc. Therefore, one skilled in the arts could readily understand that the terms used herein may also refer to their equivalents in any other infrastructure. For example, the term "communication device" used herein may refer to an IoT device (such as, a vehicle, a home appliance, a wearable device, etc.), a field device, a terminal device, a mobile device, a mobile terminal, a mobile station, a user device, a user equipment (UE), a user terminal, a wireless device, a wireless terminal, or any other equivalents. For another example, the term "authentication server" used herein may refer to a device which may host an authentication service for other devices.

As mentioned above, authentication is typically required for an IoT device. Single factor authentication (e.g., ID and password) is familiar and widely used. However, if the password is not managed in a secure way, the authentication can be easily broken by an attacker. In such a case, multiple-factor authentication is introduced for stronger authentication.

An element is users' reliance on default usernames and passwords. In particular, there is a tendency of many web cameras, DVRs (Digital Video Recorder), routers and other devices to use default passwords, and many users of such devices contribute to the security problem given their propensity for using and reusing insecure passwords. For example, there is the possibility for security cameras and other IoT devices to use a default username and password that are not exposed to the user but known to the device manufacturer or operator to enable remote management. This log-in information could enable an attacker to open a remote shell and attack. For another example, original equipment manufacturers (OEMs) intentionally use the same default password for all devices, because it reduces manufacturing costs, and likely to reduce customer support calls after release.

Compared to the single-factor authentication, the multiple-factor authentication is stronger but also more expensive and complex, requiring more resources of device and multiple steps with secure way. For instance, using one-time password/text via a SMS (Short Messaging Service) as the second authentication factor is strong but need SMS service interaction on client/IoT devices. The IoT device needs much more resources to support this kind of services. It will be a burden of small IoT devices.

To support stronger authentication, an IoT device must consider power consumption, memory size, processing power, multiple network protocols, and so on. Those factors make small or simple IoT devices hard to support multi-factor authentication. Therefore, a new scheme is needed for IoT devices that have limited resources for security.

Fig. 1 is an overview diagram illustrating an exemplary IoT network 10 in which authentication for IoT devices according to an embodiment of the present disclosure is applicable. As shown in Fig. 1, the network 10 may comprise one or more IoT devices, for example, the IoT devices 120-1 through 120-5 (hereinafter, collectively referred to as the IoT devices 120), and an authentication server 125. In some embodiments, the authentication server 125 may provide authentication services for the IoT devices 120.

As shown in Fig. 1, when an IoT device (e.g., the IoT devices 120-3, 120-4, or 120-5) is successfully authenticated by the authentication server 125, they will be regarded as a part of a secure zone (or a private network) 130 in which the IoT devices may communicate with each other safely. For those IoT devices which have not been authenticated yet or failed in the authentication, for example, the IoT devices 120-1 and 120-2, they cannot access any resource/services in the secure zone 130 and/or cannot be accessed by any device in the secure zone 130.

Further, as also shown in Fig. 1, a user 111-U may operate the IoT devices, for example, with his/her mobile device 111-D (e.g., a smart phone). In such a case, the user 111-U and the mobile device 111-D are considered as a single entity which may facilitate the IoT devices in the authentication procedure as will be explained later. However, please note that the user/mobile device 111 is not essential to some embodiments of the present disclosure, and therefore they may be omitted from these embodiments.

As shown in Fig. 1, the IoT devices 120 may comprise home appliance (such as, the air conditioner 120-1, the washing machine 120-2), a desktop PC 120-3, a printer 120-4, and a surveillance camera 120-5. However, the present disclosure is not limited thereto, and these are shown for the purpose of illustration only. In some other embodiments, the IoT devices 120 may comprise any of pipeline sensors (such as, flow meters, thermometers, pressure sensors, etc.), connected vehicles (such as, automated vehicles, unmanned aerial vehicles (UAVs), etc.), wearable devices (such as, fitness trackers, smart watches, smart goggles, head mounted devices (HMDs)) or any other communication device, or any combination thereof.

Referring back to Fig. 1, when the user 111-U who just bought and installed a new air conditioner 120-1 and a new washing machine 120-2 in his/her home tries to connect the air conditioner 120-1 and the washing machine 120-2 to the network 10 for subsequent operations (e.g., temperature/humidity monitoring/controlling by the air conditioner 120-1 or remote controlling of the washing machine 120-2), these IoT devices have to be authenticated before they can communicate with other IoT devices in the secure zone 130. Due to the limited capabilities, for example, in terms of processing power, memory size, etc., these IoT devices 120-1 and 120-2 may not be able to perform a strong authentication mechanism, such as the multi-factor authentication as mentioned above. In such a case, a new authentication mechanism is needed.

The general idea of some embodiments of the present disclosure is to utilize time varying data generated or otherwise known by an IoT device for authentication. For example, when the air conditioner 120-1 is being operated, it may generate many pieces of time varying data, such as, temperature/humidity/fan speeds, etc., and these data may be variable over time. Therefore, if the authentication server 125 is somehow aware of such time varying data, then these data may be used for a strong authentication mechanism since it would be a completely wild guess for a third party to figure out a correct response to a challenge based on these time-varying data. Please note that the term "time varying data" used herein may refer to any data which may be variable over time, such as, sensing data (e.g., temperature, humidity, fan speed, etc.), timestamp, login, log, commands for IoT devices, etc.

Next, an overall authentication procedure based on time varying data will be described with reference to Fig. 2.

Fig. 2 is a diagram illustrating an exemplary overall procedure for authenticating IoT devices (e.g. the IoT devices 120 shown in Fig. 1) according to an embodiment of the present disclosure. As shown in Fig. 2, multiple entities may be involved in this procedure, comprising the user/mobile device 111, the IoT device 120, the authentication server 125, a database for device information 205, a database for time varying data 210, and the secure zone 130. However, please note that one or more of these entities are not essential to some embodiments of the present disclosure, and therefore they can be omitted in these embodiments. Further, some of the entities may be combined into one, and/or one of the entities may be distributed across multiple physical locations. For example, the authentication server 125 and the database 210 may be incorporated or otherwise collocated within a same piece of physical hardware. For another example, the secure zone 130 may comprise multiple nodes distributed across multiple locations, rather than a same location.

Referring to Fig. 2, the overall procedure may comprise a procedure 220 in which the IoT device 120 may be registered at the authentication server 125 with or without the help of the user/mobile device 111, and/or may negotiate parameters for authentication with the authentication server 125, which will be described in details with reference to Fig. 3. In some embodiments, an initial registration procedure for the IoT device 120 is required for accurately managing and operating the IoT device 120.

Further, the overall procedure may further comprise another procedure 230 in which the IoT device 120 may authenticate itself with the authentication server 125 based on time varying data associated with the IoT device 120, which will be described in details with reference to Fig. 4. Further, when successfully authenticated, the IoT device 120 may communicate with the secure zone 130 with or without the help of the authentication server 125, which will be described in details with reference to Fig. 5.

Please note that, the procedure 220 may not be essential to some embodiments of the present disclosure. For example, the parameters required for authentication may be pre-configured by the IoT device manufacturer during the manufacturing of the IoT device 120, and therefore the procedure 220 may be not needed.

Fig. 3 is a diagram illustrating exemplary procedures for registering an IoT device (e.g., the IoT device 120) according to an embodiment of the present disclosure. Fig. 3 shows two different procedures for registering the IoT device 120 with the authentication server 125, an automatic registration procedure and a manual registration procedure.

Before the automatic registration procedure begins, the IoT device 120 may be attached with a label on which information for registering this IoT device 120 may be printed, as indicated by the step 310. For example, a Quick Response (QR) code (or pattern) may be printed on the label. The QR code or pattern may contain information related to the IoT device 120, such as, its serial number, model number, a link to the authentication server 125, or any other information required for registration. For another example, a bar code may be printed on the label, and the bar code may contain the information.

At step 315, the user/mobile device 111 may scan the label (e.g. the QR code or pattern) to start the automatic registration procedure. For example, the mobile device 111 may capture a picture of the QR code or pattern and decode the captured picture to obtain the information required for authentication of the IoT device 120, such as, the serial number of the IoT device 120, a link to the authentication server 125, etc.

Once the serial number of the IoT device 120 and the link to the authentication server 125 are obtained, the mobile device 111 may transmit a registration request for the IoT device 120 to the authentication server 125 with the obtained serial number at step 320. Upon reception of the registration request, the authentication server 125 may transmit a request for device information for the IoT device 120 to the database for device information 205 at step 325 together with the serial number which identifies the IoT device 120, and receives some static device information from the database 205 at step 330. In some embodiments, the static device information may comprise but not limited to any of model number, manufacturer, operator, media access control (MAC) address, configuration, user profile, or any combination thereof, for authentication management. In some embodiments, the static device information may be previously stored in the database 205 by the manufacturer or the retailer of the IoT device 120 during or after the manufacturing of the IoT device 120 for future usage.

At step 335, the authentication server may transmit a registration response to the mobile device 111 at least partially based on the retrieved static device information. For example, if no static device information corresponding to the IoT device 120 is received from the database 205, then the authentication server 125 may transmit a registration response indicating a failure of the device registration. For another example, if the received static device information shows that the IoT device 125 was previously registered, then the authentication server 125 may transmit a registration response indicating such a situation to the mobile device 111.

Further, at step 340, the mobile device 111 and/or the IoT device 120 may negotiate parameters for authentication of the IoT device 120 with the authentication server 125. Please note that the step 340 may be a part of the steps 320/335 or a different step than the steps 320/335. In other words, the parameter negotiation may be conducted during or after the registration. Further, the parameter negotiation may be conducted between the IoT device 120 and the authentication server 125 directly, or via the mobile device 111 indirectly.

In some embodiments, the parameters which may be negotiated between the IoT device 120 and the authentication server 125 may comprise a number of multiple pieces of time varying data to be stored at the IoT device 120 and the authentication server 125 (or any database accessible to the authentication server 125, such as the database 210) to have a same size of queue for storing the time varying data at the IoT device 120 and the authentication server 125 (or any database accessible to the authentication server 125, such as the database 210).

In some embodiments, the parameters may comprise a type of the multiple pieces of data to be stored at the IoT device 120 and the authentication server 125 (or any database accessible to the authentication server 125, such as the database 210), such that only the time varying data having the negotiated type will be transmitted to the authentication server 125 (or any database accessible to the authentication server 125, such as the database 210) and stored at the IoT device 125 and the authentication server 125 (or any database accessible to the authentication server 125, such as the database 210).

In some embodiments, the parameters may comprise a number of rounds for authentication, such that the overall authentication procedure may comprise as many rounds of authentication as the negotiated number of rounds to improve the authentication strength.

In some embodiments, the parameters may comprise an indicator indicating whether communication between the IoT device 120 and the authentication server 125 is to be encrypted or not. With the encrypted communication, the security of the authentication may be further improved.

Although these parameters may be negotiated between the IoT device 120 and the authentication server 125, the parameters may be previously agreed and configured in the IoT device 120 and the authentication server 125 in some other embodiments, and therefore the step 340 is optional in these embodiments.

Further, the present disclosure is not limited to the parameters mentioned above, and in some other embodiments, the parameters actually used may be less, more, or different than those listed above.

Below please find a specific example of the negotiation procedure for illustration purpose only. In some embodiments, the IoT device 120 may provide possible negotiation options to the authentication server 125 (directly or via the mobile device 111 indirectly), and then the authentication server 125 may decide the exact option for further authentication.

For example, the IoT device 120 may transmit Message#1 to the authentication server 120 for parameter selection:

Message#1: {

"deviceInfo": {

"ipv4Address": "192.168.150.2",

"deviceId" : "IoT-Ericsson-001",

}

"authNegotiation": {

"maxQueueSize" : 128,

"supportedTimeVaryingData" : ["temperature", "humidity", "pressure", "logon"]

}

In the Message #1, the IoT device 120 proposes a maximum number of 128 for the size of the queue for storing time varying data and four types of data, "temperature", "humidity", "pressure", and "logon", to be used for authentication.

Upon reception of the Message #1, the authentication server 125 may transmit Message#2 to the IoT device 120 to indicate its selection of the parameters.

Message#2: {

"serverInfo": {

"ipv4Address": "192.168.150.3",

"serverId" : "Server-Ericsson-001",

}

"authNegotiation": {

"selectedQueueSize" : 128,

"selectedTimeVaryingData" : ["temperature", "humidity" ]

}

In the Message #2, the authentication server 125 informs the IoT device 120 that a maximum number of 128 is used as the size of the queue for storing time varying data, and that only two from the four types of data, "temperature" and "humidity" are used for authentication.

With this automatic registration procedure, the user 111 may finish the registration of the IoT device 120 by simply scanning the QR code or pattern on the IoT device 120, thereby simplifying the operations and avoiding any potential mistakes during the procedure.

As also shown in Fig. 3, a manual registration will be described with reference to steps 350 through 365. At step 350, instead of scanning the QR code or pattern, the user 111 has to obtain the static device information from the IoT device 120 manually. For example, the user 111 may have to read the nameplate on the IoT device 120 to find out its serial number, MAC address, configuration, and/or the link to the authentication server, etc. and fill them into an electronic form manually at step 350. After that, the mobile device 111 may transmit a registration request for the IoT device 120 to the authentication server 125 at step 355 and receives a registration response from the authentication server 125 at step 360 in a similar manner to the

steps

320 and 335. Further, similar to the step 340, the IoT device 120 may negotiate the parameters for authentication with the authentication server 125 at step 365 with or without the help of the mobile device 111.

With this manual registration procedure, the user 111 may also finish the registration of the IoT device 120.

Although Fig. 3 shows an embodiment in which the mobile device 111 is involved, the present disclosure is not limited thereto. In some other embodiments, the IoT device 120 may register itself to the authentication server 125 upon power up and properly configuration of its network connection, and therefore the mobile device 111 is not essential to the registration procedure in these or other embodiments.

After the registration, the registered IoT device 120 may request authentication to the authentication server 125. If the IoT device 120 is new, i.e., no or less previous time varying data is stored at the IoT device 120 and the authentication server 125 (or a database accessible to the authentication server 125), for example, less than the negotiated number of multiple pieces of time varying data to be stored at the IoT device 120 and the authentication server 125, then the authentication server 125 may verify the IoT device 120 with static information retrieved during the device registration, e.g. IoT identifier. If the device is not new, i.e. there is enough time varying data stored at the IoT device 120 and the authentication server 125 (or a database accessible to the authentication server 125, such as the database 210), the authentication server 125 may verify the IoT device 120 based on the stored time varying data.

Fig. 4 is a diagram illustrating an exemplary procedure for authenticating an IoT device (e.g. the IoT device 120) according to an embodiment of the present disclosure. Before the authentication procedure begins, the IoT device 120 may transmit new or latest time varying data to the authentication server 125 and/or the database 210 at step 410a/410b, for future usage. After that the time varying data may be stored and maintained at the IoT device 120 and the database 210, which will be described in details with reference to Fig. 6.

For example, the IoT device 120 may be a temperature/pressure/humidity sensor, and the time varying data may be data sensed by the sensor. Below please find some specific time varying data which will be transmitted by the IoT device 120 to the authentication server 125/the database 210.

Message#1: {

"eventSource": {

"timestamp": "2020-10-28T08:45:45.001",

"ipv4Address": "192.168.150.2",

"deviceId" : "IoT-Ericsson-Temp001",

}

"eventData": [

{"sensorId" : "SENSOR-001"},

{"eventType": "temperature"},

{"data" : 36.1}

],

}

Message#2: {

"eventSource": {

"timestamp": "2020-10-28T09:15:00.001",

"ipv4Address": "192.168.150.2",

"deviceId" : "IoT-Ericsson-Temp001",

}

"eventData": [

{"sensorId" : "SENSOR-001",

{eventType": "humidity"},

{"data" : 999}

],

}

Further, the time varying data generated by the IoT device 120, which has a different type than those negotiated and agreed between the IoT device 120 and the authentication server 125, will not be transmitted to the authentication server 125/the database 210. Below please find a specific piece of time varying data which will not be transmitted by the IoT device 120 to the authentication server 125/the database 210.

Message#3:

{

"eventSource": {

"timestamp": "2020-10-28T09:00:45.001",

"ipv4Address": "192.168.150.2",

"deviceId" : "IoT-Ericsson-Temp001",

}

"eventData": [

{"sensorId" : "SENSOR-001",

{eventType": " pressure"},

{"data" : 999}

],

}

With the steps 410a and/or 410b, the latest time varying data may be synchronized between the IoT device 120 and the authentication server 125 to make sure the latest data may be used for authentication.

The authentication procedure shown in Fig. 4 may be initiated by the IoT device 120 or the authentication server 125. For example, at step 415, the IoT device 120 may initiate an authentication request to the authentication server 125 for device authentication. However, in some other embodiments, the authentication server 125 may decide to authenticate the IoT device 120, for example, due to expiry of the previous authentication, and therefore the step 415 is optional.

No matter whether the authentication is initiated by the IoT device 120 or the authentication server 125, the authentication server 125 may begin the authentication procedure by selecting, at step 420, a piece of time varying data (e.g. the i ^th time varying data) from multiple pieces of time varying data which were previously communicated between the IoT device 120 and the authentication server 125/database 210 and currently stored in the IoT device 120 and the database 210, as shown in Fig. 6.

Upon the selection at step 420, the authentication server 125 may retrieve the selected data from the database 210 at steps 425 and 430. Please note that if the time varying data is stored locally at the authentication server 125, then the steps 425 and 430 may be omitted. Further, after the step 420, the authentication server 125 may also retrieve the selected data from the IoT device 120 at steps 435 and 440. Please note that the steps 425 and 430 may be performed before, after, or at least partially simultaneously with the steps 435 and 440.

Upon reception of the i ^th time varying data from the IoT device 120 and the database 210, the authentication server 125 may compare the selected data from the IoT device 120 and the database 210 to make sure whether they are consistent with each other or not.

At step 450, based on the result of the comparison, the authentication server 125 may transmit an authentication result to the IoT device 120. For example, when the comparison indicates that the data from the IoT device 120 is identical to that from the database 210, the authentication server 125 may transmit an authentication result indicating a successful authentication to the IoT device 120. For another example, when the comparison indicates that the data from the IoT device 120 is not identical to that from the database 210, the authentication server 125 may transmit an authentication result indicating a failed authentication to the IoT device 120, or just transmit nothing. For the latter case, the IoT device 120 may assume a failed authentication after a certain period of time elapses, and therefore the step 450 is optional in some embodiments.

Further, as mentioned earlier, if the agreed parameters comprise the number m of rounds for authentication, and the number m is greater than 1, then the steps 420 through 445 may be repeated for as many rounds as the agreed number m. In other words, the steps 420 through 445 may be performed according to the negotiated number of rounds for authentication. For example, if the agreed number m is 2, then after comparing the i ^th time varying data in the first round, another piece of time varying data (e.g. j ^th) may be selected to be compared in the second round. In some embodiments, the overall authentication is considered as a success only when authentication in each of the rounds is successful. In some other embodiments, the overall authentication may be considered as a success when the ratio of the number of successful rounds over the number of all rounds is greater than or equal to a negotiated or predetermined threshold.

Although it is shown in Fig. 4 that the time varying data itself is transmitted and compared, the present disclosure is not limited thereto. In some other embodiments, some other data which may uniquely identify the time varying data may be transmitted and compared. For example, such data could be a digital digest of corresponding time varying data. In some embodiments, the digital digest may be generated from the time varying data by the MD5 or SHA1 algorithm. In such cases, the authentication server 125 may just compare the digital digest received from the IoT device 120 and the database 210 to determine whether the authentication is successful or not.

Further, as mentioned above, if the agreed parameters comprise an indicator indicating whether communication between the IoT device 120 and the authentication server 125 is to be encrypted or not, then the message exchanged between the IoT device 120 and the authentication server 125 may be encrypted to further improve the security of the authentication procedure.

Fig. 5 is a diagram illustrating exemplary procedures for accessing a secure zone (e.g. the secure zone 130) by an authenticated IoT device (e.g. the IoT device 120) according to an embodiment of the present disclosure. There are two methods for the IoT device 120 to access the secure zone 130, direct access and indirect access via the authentication server 125 as shown in Fig. 5.

As shown in Fig. 5, the IoT device 120 may authenticate itself with the authentication server 125. When the authentication is successful, the authentication server 125 may transmit a token to the IoT device 120 for accessing the secure zone 130 at step 510. In some embodiments, the step 510 may be a part of the step 450 shown in Fig. 4, that is, the token may be carried by the authentication result message shown in Fig. 4.

Upon reception of the token, the IoT device 120 may attempt to access the secure zone 130, for example, by transmitting an access request or a report (e.g., sensing data) to a node in the secure zone 130 with the token issued by the authentication server 125. In some embodiments, the node in the secure zone 130 may verify the token with the authentication server 125 at

steps

525 and 530, and determine whether the access request or the report is acceptable or not at least partially based on the verification. For example, if the verification result at step 530 indicates that the token is expired or fake, then the node may transmit an access response to the IoT device 120 to reject its access request or just transmit nothing. For another example, if the verification result at step 530 indicates that the token is valid, then the node may transmit an access response to the IoT device 120 to indicate a successful access, for example, by providing required services or an acknowledgement of the report.

In some embodiments where the IoT device 120 is not capable of handling the token, for example, due to limited processing power or limited memory, the IoT device 120 may try to access the secure zone 130 via the authentication server 125 in an indirect manner. To be specific, at step 550, upon the successful authentication, the IoT device 550 may transmit an access request or a report to the authentication server 125, and, at step 555, the authentication server 125 may forward the access request or the report to the secure zone 130 in response to determining that the IoT device 120 was previously successfully authenticated. Similar to the

steps

535 and 540, the node in the secure zone 130 may determine whether such a request or report is acceptable or not at step 560 and provide a corresponding response to the authentication server 125. Upon reception of the access response, the authentication server 125 may forward it to the IoT device 120 at step 570 and complete the access procedure.

With the procedures shown in Fig. 2 through Fig. 5, it is clear that a strong authentication may be achieved without imposing a heavy burden on the IoT device 120 which may have limited resources for the authentication procedure.

Further, Fig. 2 through Fig. 5 show embodiments where the IoT device 120 may perform the procedures on its own, but the present disclosure is not limited thereto. For example, for IoT devices with very limited resources, such as legacy sensors or existing devices, they cannot even store or process time varying data for authentication locally, or they do not have the ability to process the messages exchanged between the IoT devices and the authentication server. In such a case, a proxy server may be set up for the IoT devices, and operated on behalf of the IoT devices. For example, any data transmitted from or received by the IoT devices may be forwarded to the proxy server, and the proxy server may use these data for authentication with the authentication server as if the data is its own data. In such a case, the IoT devices may access the secure zone via the proxy server without any change in their software/hardware.

The time varying data of the device may be stored within the IoT device 120 and the authentication server 125. The data will be updated both sides when the IoT device 120 performs pre-defined digital activities including login information, transmitted data, etc. In other words, the embodiments provide a way of strong authentication and validation of IoT devices by taking use of time-varying data such as login information, command, sensing data, etc., which enables protecting IoT devices from unauthorized access and control. Further, this authentication mechanism does not require data encryption that is an expensive way and is simpler than existing security solutions such as IP-SEC, Pre-shared key using SSH, etc. In other words, this authentication mechanism does not require high computing power, which helps low battery consumption of IoT device.

Further, this mechanism is scalable, and therefore it is readily applicable to an IoT network comprising numerous IoT devices. Further, it is easy to control the security grade of authentication, for example, by requiring different security levels (or different rounds of authentication). Furthermore, the mechanism does not have to manage ID and password for IoT devices, and it can be used in many different applications comprising smart home, smart factory, smart grid, even to a smart city.

Fig. 6 is a diagram illustrating how time varying data is synchronized between IoT devices (e.g. the IoT devices 120-1 through 120-n, hereinafter collectively 120) and an authentication server (e.g. the authentication server 125) according to an embodiment of the present disclosure.

As shown in Fig. 6, each of the IoT devices 120-1 through 120-n will maintain its own time varying data table 610-1 through 610-n (hereinafter collectively 610), respectively. For example, each of the time varying data tables 610 may be a First-In-First-Out (FIFO) queue, and the size of the queue may be negotiated as mentioned above. In other words, when the queue 610 is full of time varying data and a new data is coming in (e.g. indicated by the arrow above the word "New"), the oldest piece of data in the queue 610 (e.g., indicated by the arrow above the word "Old") will be removed from the queue 610. At the same time, the authentication server 125 will maintain a same table (or FIFO queue) for each of the IoT devices 120 to guarantee the synchronization between the tables 610 and 620. As shown in Fig. 6, the queues 620-1 through 620-n will be maintained at the authentication server 125 or the database 210 independently to each other.

In some embodiments, the time varying data removed from the queue 620 may not be deleted permanently, but will be stored for a period time, just in case there is any error in the synchronization of data and the updated queue 620 has to be reverted to its previous state.

As shown in Fig. 6, each of the stored time varying data may be assigned with an index (e.g., TVDd( i), i=2 at the IoT device #1 120-1 and TVDs( i), i=2 at the authentication server 125), and the index may be used in the

steps

425 and 435, respectively, for retrieving corresponding data.

Fig. 7 is a diagram illustrating an exemplary scenario 70 in which authentication for a roaming IoT device (e.g. a vehicle 730-1) according to an embodiment of the present disclosure is applicable. As shown in Fig. 7, there are two

private networks

710 and 720 which may be communicatively connected through a public network 730 (e.g., the Internet or any untrusted network). In some embodiments, the

private networks

710 and 720 are secure zones, and the IoT devices therein are authenticated and trustworthy. For example, the IoT device 730-1, which in the embodiment may be a vehicle, may authenticate itself with the authentication server #1 715, for example, by the authentication procedure discussed with reference to Fig. 2 through Fig. 5. In such a case, the authentication server #1 715 may maintain a time varying data table for the IoT device 730-1 for subsequent authentication.

As shown in Fig. 7, the vehicle 730-1 may travel to the other private network #2 720, and therefore the vehicle 730-1 has to authenticate itself with the authentication server #2 725 before it can join the secure zone or the private network #2 720. Instead of registering with the authentication server #2 725, the IoT device 730-1 may authenticate itself directly with the authentication server #2, and the authentication server #2 may retrieve the required time varying data from the authentication server #1 715 in a secure manner.

In the embodiment shown in Fig. 7, such a retrieval of the data may be conducted based on the block-chain technology. In other words, the authentication server #1 715 (or any database accessible to the authentication server #1 715) and the authentication server #2 725 (or any database accessible to the authentication server #2 725) may be nodes in a same blockchain network which is hosted across the public network 730. In such a case, the time varying data tables may be maintained in the blockchain network in a distributed and secure manner. That is, the authentication server #2 725 may retrieve the time varying data table for the vehicle 730-1 from the blockchain network. With this blockchain-based distributed authentication procedure, a roaming IoT device, such as a vehicle, may be authenticated easily.

For example, when the IoT device 730-1 is authenticated with the authentication server #1 715, the authentication server #1 715 may publish the time varying data table maintained for the IoT device 730-1 to other nodes in the blockchain network, and later when the IoT device 730-1 is roaming to the private network #2 720 and authenticated with the authentication server #2 725, the authentication server #2 725 may publish the updated time varying data table maintained for the IoT device 730-1 to other nodes in the blockchain network, and therefore the blockchain network, as a whole, maintain the latest table for the IoT device 730-1 for authentication no matter where the IoT device 730-1 is located.

Fig. 8 is a flow chart of an exemplary method 800 for authentication according to an embodiment of the present disclosure. The method 800 may be performed at a communication device (e.g. the IoT device 120). The method 800 may comprise step S810 and step S820. However, the present disclosure is not limited thereto. In some other embodiments, the method 800 may comprise more steps, less steps, different steps or any combination thereof. Further, the steps of the method 800 may be performed in a different order than that described herein. Further, in some embodiments, a step in the method 800 may be split into multiple sub-steps and performed by different entities, and/or multiple steps in the method 800 may be combined into a single step.

The method 800 may begin at step S810 where a request message for requesting at least one of multiple pieces of data may be received from an authentication server, the multiple pieces of data being communicated by the communication device.

At step S820, a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data may be transmitted to the authentication server in response to the request message.

In some embodiments, the method 800 may further comprise: receiving, from the authentication server, an authentication result message indicating whether the communication device is successfully authenticated by the authentication server or not. In some embodiments, each of the multiple pieces of data may be a piece of time-varying data. In some embodiments, each of the multiple pieces of data may have at least one type of: time-varying sensing data transmitted by the communication device; timestamp data transmitted and/or received by the communication device; time-varying login data transmitted by the communication device; time-varying log data transmitted by the communication device; and time-varying command data received at the communication device. In some embodiments, the multiple pieces of data may be stored at the communication device and each of the multiple pieces of data may be assigned with an index, wherein the request message may comprise at least one index indicating the at least one piece of data.

In some embodiments, before receiving the request message, the method 800 may further comprise negotiating, with the authentication server, at least one parameter of: a number of the multiple pieces of data to be stored at the communication device; a type of the multiple pieces of data to be stored at the communication device; a number of rounds for authentication; and whether communication between the communication device and the authentication server is to be encrypted or not. In some embodiments, the method 800 may further comprise: adjusting the stored multiple pieces of data in response to transmitting and/or receiving a new piece of data of the negotiated type. In some embodiments, the multiple pieces of data may be stored in a First-In-First-Out (FIFO) queue. In some embodiments, the step of receiving a request message and the step of transmitting a response message may be performed according to the negotiated number of rounds for authentication. In some embodiments, the method 800 may further comprise: accessing one or more services and/or resources hosted in a secure zone via the authentication server in response to the authentication result message indicating successful authentication with the authentication server. In some embodiments, the method 800 may further comprise: initiating a re-synchronization procedure with the authentication server to have the multiple pieces of data synchronized with the multiple pieces of data which are maintained by the authentication server in response to the authentication result message indicating failed authentication with the authentication server.

In some embodiments, a message exchanged between the communication device and the authentication server may be encrypted. In some embodiments, the communication device may have a label that is configured to provide information for a registration procedure for the communication device. In some embodiments, the label may be a Quick Response (QR) code containing information for an automatic registration of the communication device. In some embodiments, after negotiating, with the authentication server, at least one parameter and before receiving, from the authentication server, a request message, the method 800 may further comprise: transmitting, to the authentication server, an authentication request message for requesting authentication of the communication device. In some embodiments, the method 800 may further comprise: receiving, from the authentication server, a static request message for requesting static data which is preconfigured in the communication device; and transmitting, to the authentication server, a static response message comprising the required static data in response to the static request message. In some embodiments, the static data may comprise an identifier of the communication device. In some embodiments, the multiple pieces of data may be received from another communication device.

In some embodiments, the method 800 may further comprise: receiving, from another authentication server, another request message for requesting at least one of the multiple pieces of data; and transmitting, to the other authentication server, another response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data in response to the other request message. In some embodiments, the data uniquely identifying the at least one piece of data may be a digital digest of the at least one piece of data.

Fig. 9 is a flow chart of an exemplary method 900 for authentication according to an embodiment of the present disclosure. The method 900 may be performed at an authentication server (e.g. the authentication server 125). The method 900 may comprise step S910, S920, and step S930. However, the present disclosure is not limited thereto. In some other embodiments, the method 900 may comprise more steps, less steps, different steps or any combination thereof. Further the steps of the method 900 may be performed in a different order than that described herein. Further, in some embodiments, a step in the method 900 may be split into multiple sub-steps and performed by different entities, and/or multiple steps in the method 900 may be combined into a single step.

The method 900 may begin at step S910 where a request message for requesting at least one of multiple pieces of data may be transmitted to a communication device, the multiple pieces of data being communicated by the communication device and stored in a database which is accessible to the authentication server.

At step S920, a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data may be received from the communication device.

At step S930, whether the communication device is successfully authenticated or not is determined at least partially based on the response message.

In some embodiments, the method 900 may further comprise: transmitting, to the communication device, an authentication result message indicating whether the communication device is successfully authenticated or not based on the determination. In some embodiments, the step of determining whether the communication device is successfully authenticated or not may comprise: comparing the at least one piece of data comprised in the response message with corresponding at least one piece of data retrieved from the database, respectively; and determining the communication device is successfully authenticated or not in response to the result of comparison. In some embodiments, the step of determining whether the communication device is successfully authenticated or not may comprise: comparing the data comprised in the response message with data derived from at least one corresponding piece of data retrieved from the database in a same way in which the data comprised in the response message is derived, respectively; and determining the communication device is successfully authenticated or not in response to the result of comparison. In some embodiments, each of the multiple pieces of data may be a piece of time-varying data. In some embodiments, each of the multiple pieces of data may have at least one type of: time-varying sensing data transmitted by the communication device; timestamp data transmitted and/or received by the communication device; time-varying login data transmitted by the communication device; time-varying log data transmitted by the communication device; and time-varying command data received at the communication device.

In some embodiments, the database may be hosted locally at or remote to the authentication server, and each of the multiple pieces of data is assigned with an index, wherein the request message may comprise at least one index indicating the at least one piece of data. In some embodiments, before transmitting the request message, the method 900 may further comprise negotiating, with the communication device, at least one parameter of: a number of the multiple pieces of data to be stored at the database; a type of the multiple pieces of data to be stored at the database; a number of rounds for authentication; and whether communication between the communication device and the authentication server is to be encrypted or not. In some embodiments, the method 900 may further comprise: causing the database to adjust the multiple pieces of data in response to transmitting and/or receiving a new piece of data of the negotiated type to and/or from the communication device. In some embodiments, the multiple pieces of data may be stored in a First-In-First-Out (FIFO) queue. In some embodiments, the step of transmitting a request message, the step of receiving a response message, and the step of determining whether the communication device is successfully authenticated or not may be performed according to the negotiated number of rounds for authentication. In some embodiments, the step of determining whether the communication device is successfully authenticated or not at least partially based on the response message may comprise: determining whether the communication device is successfully authenticated or not based on the response message and the one or more additional response messages.

In some embodiments, the method 900 may further comprise: accessing one or more services and/or resources hosted in a secure zone on behalf of the communication device in response to the authentication result message indicating successful authentication. In some embodiments, the method 900 may further comprise: performing a re-synchronization procedure with the communication device to cause the database to have the multiple pieces of data synchronized with those stored at the communication device in response to the authentication result message indicating failed authentication with the authentication server. In some embodiments, a message exchanged between the communication device and the authentication server may be encrypted. In some embodiments, before negotiating, with the communication device, at least one parameter, the method 900 may further comprise: receiving a registration request for registering the communication device, the registration request comprising an identifier of the communication device; transmitting, to a device information database, a device information request for static data of the communication device, the device information request comprising the identifier of the communication device; and receiving the static data from the device information database. In some embodiments, after negotiating, with the communication device, at least one parameter and before transmitting, to the communication device, a request message, the method 900 may further comprise: receiving, from the communication device, an authentication request message for requesting authentication of the communication device.

In some embodiments, the method 900 may further comprise: transmitting, to the communication device, a static request message for requesting the static data; receiving, from the communication device, a static response message in response to the static request message; and determining whether the communication device is successfully authenticated or not based on the static response message. In some embodiments, the authentication server may be a node of a block chain network, and the multiple pieces of data are maintained and shared by the block chain network. In some embodiments, before the step of transmitting, to the communication device, the request message, the method 900 may further comprise: retrieving, from the block chain network, the multiple pieces of data for the communication device. In some embodiments, the data uniquely identifying the at least one piece of data may be a digital digest of the at least one piece of data.

In some embodiments, the method 900 may further comprise: starting a timer for the communication device in response to determining that the communication device is successfully authenticated; and determining that the authentication of the communication device is expired upon the expiration of the timer. In some embodiments, the method 900 may further comprise: transmitting, to a second communication device, a second request message for requesting at least one of multiple pieces of second data, the multiple pieces of second data being communicated by the second communication device and stored in the database; receiving, from the second communication device, a second response message comprising the at least one piece of second data which is requested and/or data uniquely identifying the at least one piece of second data; and determining whether the second communication device is successfully authenticated or not at least partially based on the second response message.

Fig. 10 schematically shows an embodiment of an arrangement 1000 which may be used in a communication device (e.g., the IoT device 120) or an authentication server (e.g. the authentication server 125) according to an embodiment of the present disclosure. Comprised in the arrangement 1000 are a processing unit 1006, e.g., with a Digital Signal Processor (DSP) or a Central Processing Unit (CPU). The processing unit 1006 may be a single unit or a plurality of units to perform different actions of procedures described herein. The arrangement 1000 may also comprise an input unit 1002 for receiving signals from other entities, and an output unit 1004 for providing signal(s) to other entities. The input unit 1002 and the output unit 1004 may be arranged as an integrated entity or as separate entities.

Furthermore, the arrangement 1000 may comprise at least one computer program product 1008 in the form of a non-volatile or volatile memory, e.g., an Electrically Erasable Programmable Read-Only Memory (EEPROM), a flash memory and/or a hard drive. The computer program product 1008 comprises a computer program 1010, which comprises code/computer readable instructions, which when executed by the processing unit 1006 in the arrangement 1000 causes the arrangement 1000 and/or the network elements in which it is comprised to perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 1 to Fig. 9 or any other variant.

The computer program 1010 may be configured as a computer program code structured in

computer program modules

1010A and 1010B. Hence, in an exemplifying embodiment when the arrangement 1000 is used in a communication device, the code in the computer program of the arrangement 1000 includes: a module 1010A for receiving, from an authentication server, a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device; and a module 1010B for transmitting, to the authentication server, a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data, in response to the request message.

Further, the computer program 1010 may be configured as a computer program code structured in

computer program modules

1010C, 1010D, and 1010E. Hence, in an exemplifying embodiment when the arrangement 1000 is used in an authentication server, the code in the computer program of the arrangement 1000 includes: a module 1010C for transmitting, to a communication device, a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device and stored in a database which is accessible to the authentication server; a module 1010D for receiving, from the communication device, a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data, and a module 1010D for determining whether the communication device is successfully authenticated or not at least partially based on the response message.

The computer program modules could essentially perform the actions of the flow illustrated in Fig. 1 to Fig. 9, to emulate the communication device or the authentication server. In other words, when the different computer program modules are executed in the processing unit 1006, they may correspond to different modules in the communication device or the authentication server.

Although the code means in the embodiments disclosed above in conjunction with Fig. 10 are implemented as computer program modules which when executed in the processing unit causes the arrangement to perform the actions described above in conjunction with the figures mentioned above, at least one of the code means may in alternative embodiments be implemented at least partly as hardware circuits.

The processor may be a single CPU (Central processing unit), but could also comprise two or more processing units. For example, the processor may include general purpose microprocessors; instruction set processors and/or related chips sets and/or special purpose microprocessors such as Application Specific Integrated Circuit (ASICs). The processor may also comprise board memory for caching purposes. The computer program may be carried by a computer program product connected to the processor. The computer program product may comprise a computer readable medium on which the computer program is stored. For example, the computer program product may be a flash memory, a Random-access memory (RAM), a Read-Only Memory (ROM), or an EEPROM, and the computer program modules described above could in alternative embodiments be distributed on different computer program products in the form of memories within the UE.

Correspondingly to the method 800 as described above, an exemplary communication device is provided. Fig. 11 is a block diagram of a communication device 1100 according to an embodiment of the present disclosure. The communication device 1100 can be e.g., an IoT device. The communication device 1100 may function as an IoT device

The communication device 1100 can be configured to perform the method 800 as described above in connection with Fig. 8. As shown in Fig. 11, the communication device 1100 may comprise a receiving module 1110 configured to receive, from an authentication server, a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device; and a transmitting module 1120 configured to transmit, to the authentication server, a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data, in response to the request message.

The above modules 1110 and/or 1120 can be implemented as a pure hardware solution or as a combination of software and hardware, e.g., by one or more of: a processor or a micro-processor and adequate software and memory for storing of the software, a Programmable Logic Device (PLD) or other electronic component(s) or processing circuitry configured to perform the actions described above, and illustrated, e.g., in Fig. 8. Further, the communication device 1100 may comprise one or more further modules, each of which may perform any of the steps of the method 800 described with reference to Fig. 8.

Correspondingly to the method 900 as described above, an authentication server is provided. Fig. 12 is a block diagram of an exemplary authentication server 1200 according to an embodiment of the present disclosure. The authentication server 1200 can be e.g., the authentication server for the above communication device.

The authentication server 1200 can be configured to perform the method 900 as described above in connection with Fig. 9. As shown in Fig. 12, the authentication server 1200 may comprise a transmitting module 1210 configured to transmit, to a communication device, a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device and stored in a database which is accessible to the authentication server; a receiving module 1220 configured to receive, from the communication device, a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data; and a determining module 1230 configured to determine whether the communication device is successfully authenticated or not at least partially based on the response message.

The

above modules

1210, 1220, and/or 1230 can be implemented as a pure hardware solution or as a combination of software and hardware, e.g., by one or more of: a processor or a micro-processor and adequate software and memory for storing of the software, a Programmable Logic Device (PLD) or other electronic component(s) or processing circuitry configured to perform the actions described above, and illustrated, e.g., in Fig. 9. Further, the communication device 1200 may comprise one or more further modules, each of which may perform any of the steps of the method 900 described with reference to Fig. 9.

The present disclosure is described above with reference to the embodiments thereof. However, those embodiments are provided just for illustrative purpose, rather than limiting the present disclosure. The scope of the disclosure is defined by the attached claims as well as equivalents thereof. Those skilled in the art can make various alternations and modifications without departing from the scope of the disclosure, which all fall into the scope of the disclosure.

Claims

A method (800) at a communication device (120, 730, 1000, 1100) for authentication, the method (800) comprising:

receiving (435, S810), from an authentication server (125, 715, 725, 1000, 1200), a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device (120, 730, 1000, 1100); and

transmitting (440, S820), to the authentication server (125, 715, 725, 1000, 1200), a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data, in response to the request message.
The method (800) of claim 1, further comprising:

receiving (450), from the authentication server (125, 715, 725, 1000, 1200), an authentication result message indicating whether the communication device (120, 730, 1000, 1100) is successfully authenticated by the authentication server (125, 715, 725, 1000, 1200) or not.
The method (800) of any of preceding claims, wherein each of the multiple pieces of data is a piece of time-varying data.
The method (800) of claim 3, wherein each of the multiple pieces of data has at least one type of:

time-varying sensing data transmitted by the communication device (120, 730, 1000, 1100);

timestamp data transmitted and/or received by the communication device (120, 730, 1000, 1100);

time-varying login data transmitted by the communication device (120, 730, 1000, 1100);

time-varying log data transmitted by the communication device (120, 730, 1000, 1100); and

time-varying command data received at the communication device (120, 730, 1000, 1100).
The method (800) of any of preceding claims, wherein the multiple pieces of data are stored at the communication device (120, 730, 1000, 1100) and each of the multiple pieces of data is assigned with an index,

wherein the request message comprises at least one index indicating the at least one piece of data.
The method (800) of any of preceding claims, wherein before receiving (435) the request message, the method (800) further comprises negotiating (340, 365), with the authentication server (125, 715, 725, 1000, 1200), at least one parameter of:

a number of the multiple pieces of data to be stored at the communication device (120, 730, 1000, 1100);

a type of the multiple pieces of data to be stored at the communication device (120, 730, 1000, 1100);

a number of rounds for authentication; and

whether communication between the communication device (120, 730, 1000, 1100) and the authentication server (125, 715, 725, 1000, 1200) is to be encrypted or not.
The method (800) of claim 6, further comprising:

adjusting the stored multiple pieces of data in response to transmitting (410a, 410b) and/or receiving a new piece of data of the negotiated type.
The method (800) of claim 7, wherein the multiple pieces of data are stored in a First-In-First-Out (FIFO) queue (610).
The method (800) of any of claims 6 to 8, wherein:

the step of receiving (435) a request message and the step of transmitting (440) a response message are performed according to the negotiated number of rounds for authentication.
The method (800) of any of preceding claims, further comprising:

accessing one or more services and/or resources hosted in a secure zone (130) via the authentication server (125, 715, 725, 1000, 1200) in response to the authentication result message indicating successful authentication with the authentication server (125, 715, 725, 1000, 1200).
The method (800) of any of claims 1 to 9, further comprising:

initiating a re-synchronization procedure with the authentication server (125, 715, 725, 1000, 1200) to have the multiple pieces of data synchronized with the multiple pieces of data which are maintained by the authentication server (125, 715, 725, 1000, 1200) in response to the authentication result message indicating failed authentication with the authentication server (125, 715, 725, 1000, 1200).
The method (800) of any of preceding claims, wherein a message exchanged between the communication device (120, 730, 1000, 1100) and the authentication server (125, 715, 725, 1000, 1200) is encrypted.
The method (800) of any of preceding claims, wherein the communication device (120, 730, 1000, 1100) has a label that is configured to provide information for a registration procedure for the communication device (120, 730, 1000, 1100).
The method (800) of claim 13, wherein the label is a Quick Response (QR) code containing information for an automatic registration of the communication device (120, 730, 1000, 1100).
The method (800) of any of preceding claims, wherein after negotiating (340, 365), with the authentication server (125, 715, 725, 1000, 1200), at least one parameter and before receiving (435), from the authentication server (125, 715, 725, 1000, 1200), a request message, the method further comprises:

transmitting (415), to the authentication server (125, 715, 725, 1000, 1200), an authentication request message for requesting authentication of the communication device (120, 730, 1000, 1100).
The method (800) of claim 15, further comprising:

receiving, from the authentication server (125, 715, 725, 1000, 1200), a static request message for requesting static data which is preconfigured in the communication device (120, 730, 1000, 1100); and

transmitting, to the authentication server (125, 715, 725, 1000, 1200), a static response message comprising the required static data in response to the static request message.
The method (800) of claim 16, wherein the static data comprises an identifier of the communication device (120, 730, 1000, 1100).
The method (800) of any of preceding claims, wherein the multiple pieces of data are received from another communication device.
The method (800) of any of claims 1 to 17, further comprising:

receiving, from another authentication server (725, 1000, 1200), another request message for requesting at least one of the multiple pieces of data; and

transmitting, to the other authentication server (725, 1000, 1200), another response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data in response to the other request message.
The method (800) of any of preceding claims, wherein the data uniquely identifying the at least one piece of data is a digital digest of the at least one piece of data.
A communication device (120, 730, 1000, 1100), comprising:

a processor (1006);

a memory (1008) storing instructions (1010) which, when executed by the processor (1006), cause the processor (1006) to:

receive, from an authentication server (125, 715, 725, 1000, 1200), a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device (120, 730, 1000, 1100); and

transmit, to the authentication server (125, 715, 725, 1000, 1200), a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data, in response to the request message.
The communication device (120, 730, 1000, 1100) of claim 21, wherein the instructions (1010), when executed by the processor (1006), further cause the processor (1006) to perform the method (800) of any of claims 2 to 20.
A communication device (120, 730, 1000, 1100) adapted to:

receive, from an authentication server (125, 715, 725, 1000, 1200), a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device (120, 730, 1000, 1100); and

transmit, to the authentication server (125, 715, 725, 1000, 1200), a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data, in response to the request message.
The communication device (120, 730, 1000, 1100) of claim 22, wherein the communication device (120, 730, 1000, 1100) is further adapted to perform the method (800) of any of claims 2 to 20.
A method (900) at an authentication server (125, 715, 725, 1000, 1200) for authentication, the method comprising:

transmitting (435, S910), to a communication device (120, 730, 1000, 1100), a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device (120, 730, 1000, 1100) and stored in a database (210) which is accessible to the authentication server (125, 715, 725, 1000, 1200);

receiving (440, S920), from the communication device (120, 730, 1000, 1100), a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data; and

determining (445, S930) whether the communication device (120, 730, 1000, 1100) is successfully authenticated or not at least partially based on the response message.
The method (900) of claim 25, further comprising:

transmitting (450), to the communication device (120, 730, 1000, 1100), an authentication result message indicating whether the communication device (120, 730, 1000, 1100) is successfully authenticated or not based on the determination.
The method (900) of any of claims 25 to 26, wherein the step of determining (445) whether the communication device (120, 730, 1000, 1100) is successfully authenticated or not comprises:

comparing the at least one piece of data comprised in the response message with corresponding at least one piece of data retrieved from the database, respectively; and

determining the communication device (120, 730, 1000, 1100) is successfully authenticated or not in response to the result of comparison.
The method (900) of any of claims 25 to 26, wherein the step of determining (445) whether the communication device (120, 730, 1000, 1100) is successfully authenticated or not comprises:

comparing the data comprised in the response message with data derived from at least one corresponding piece of data retrieved from the database in a same way in which the data comprised in the response message is derived, respectively; and

determining the communication device (120, 730, 1000, 1100) is successfully authenticated or not in response to the result of comparison.
The method (900) of any of claims 25 to 28, wherein each of the multiple pieces of data is a piece of time-varying data.
The method (900) of claim 29, wherein each of the multiple pieces of data has at least one type of:

time-varying sensing data transmitted by the communication device (120, 730, 1000, 1100);

timestamp data transmitted and/or received by the communication device (120, 730, 1000, 1100);

time-varying login data transmitted by the communication device (120, 730, 1000, 1100);

time-varying log data transmitted by the communication device (120, 730, 1000, 1100); and

time-varying command data received at the communication device (120, 730, 1000, 1100).
The method (900) of any of claims 25 to 30, wherein the database (210) is hosted locally at or remote to the authentication server (125, 715, 725, 1000, 1200), and each of the multiple pieces of data is assigned with an index,

wherein the request message comprises at least one index indicating the at least one piece of data.
The method (900) of any of claims 25 to 31, wherein before transmitting (435) the request message, the method (900) further comprises negotiating (340, 365), with the communication device (120, 730, 1000, 1100), at least one parameter of:

a number of the multiple pieces of data to be stored at the database (210);

a type of the multiple pieces of data to be stored at the database (210);

a number of rounds for authentication; and

whether communication between the communication device (120, 730, 1000, 1100) and the authentication server (125, 715, 725, 1000, 1200) is to be encrypted or not.
The method (900) of claim 32, further comprising:

causing the database (210) to adjust the multiple pieces of data in response to transmitting and/or receiving (410a, 410b) a new piece of data of the negotiated type to and/or from the communication device (120, 730, 1000, 1100).
The method (900) of claim 33, wherein the multiple pieces of data are stored in a First-In-First-Out (FIFO) queue (610).
The method (900) of any of claims 32 to 34, wherein:

the step of transmitting (435) a request message, the step of receiving (440) a response message, and the step of determining (450) whether the communication device (120, 730, 1000, 1100) is successfully authenticated or not are performed according to the negotiated number of rounds for authentication.
The method (900) of claim 35, wherein the step of determining (445) whether the communication device (120, 730, 1000, 1100) is successfully authenticated or not at least partially based on the response message comprises:

determining whether the communication device (120, 730, 1000, 1100) is successfully authenticated or not based on the response message and the one or more additional response messages.
The method (900) of any of claims 25 to 36, further comprising:

accessing one or more services and/or resources hosted in a secure zone (1330) on behalf of the communication device (120, 730, 1000, 1100) in response to the authentication result message indicating successful authentication.
The method (900) of any of claims 25 to 37, further comprising:

performing a re-synchronization procedure with the communication device (120, 730, 1000, 1100) to cause the database (210) to have the multiple pieces of data synchronized with those stored at the communication device (120, 730, 1000, 1100) in response to the authentication result message indicating failed authentication with the authentication server (125, 715, 725, 1000, 1200).
The method (900) of any of claims 25 to 38, wherein a message exchanged between the communication device (120, 730, 1000, 1100) and the authentication server (125, 715, 725, 1000, 1200) is encrypted.
The method (900) of any of claims 25 to 39, wherein before negotiating (340, 365), with the communication device (120, 730, 1000, 1100), at least one parameter, the method further comprises:

receiving a registration request for registering the communication device (120, 730, 1000, 1100), the registration request comprising an identifier of the communication device (120, 730, 1000, 1100);

transmitting, to a device information database, a device information request for static data of the communication device (120, 730, 1000, 1100), the device information request comprising the identifier of the communication device (120, 730, 1000, 1100); and

receiving the static data from the device information database.
The method (900) of any of claims 25 to 40, wherein after negotiating (340, 365), with the communication device (120, 730, 1000, 1100), at least one parameter and before transmitting (435), to the communication device (120, 730, 1000, 1100), a request message, the method (900) further comprises:

receiving (415), from the communication device (120, 730, 1000, 1100), an authentication request message for requesting authentication of the communication device (120, 730, 1000, 1100).
The method (900) of claim 41, further comprising:

transmitting, to the communication device (120, 730, 1000, 1100), a static request message for requesting the static data;

receiving, from the communication device (120, 730, 1000, 1100), a static response message in response to the static request message; and

determining whether the communication device (120, 730, 1000, 1100) is successfully authenticated or not based on the static response message.
The method (900) of any of claims 25 to 42, wherein the authentication server (715, 725) is a node of a block chain network, and the multiple pieces of data are maintained and shared by the block chain network.
The method (900) of claim 43, wherein before the step of transmitting (435), to the communication device (730-1), the request message, the method (900) further comprises:

retrieving, from the block chain network, the multiple pieces of data for the communication device (730-1).
The method (900) of any of claims 25 to 44, wherein the data uniquely identifying the at least one piece of data is a digital digest of the at least one piece of data.
The method (900) of any of claims 25 to 45, further comprising:

starting a timer for the communication device (120, 730, 1000, 1100) in response to determining that the communication device (120, 730, 1000, 1100) is successfully authenticated; and

determining that the authentication of the communication device (120, 730, 1000, 1100) is expired upon the expiration of the timer.
The method (900) of any of claims 25 to 46, further comprising:

transmitting, to a second communication device, a second request message for requesting at least one of multiple pieces of second data, the multiple pieces of second data being communicated by the second communication device and stored in the database;

receiving, from the second communication device, a second response message comprising the at least one piece of second data which is requested and/or data uniquely identifying the at least one piece of second data; and

determining whether the second communication device is successfully authenticated or not at least partially based on the second response message.
An authentication server (125, 715, 725, 1000, 1200), comprising:

a processor (1006);

a memory (1008) storing instructions (1010) which, when executed by the processor (1006), cause the processor (1006) to:

transmit, to a communication device (120, 730, 1000, 1100), a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device (120, 730, 1000, 1100) and stored in a database (210) which is accessible to the authentication server (125, 715, 725, 1000, 1200);

receive, from the communication device (120, 730, 1000, 1100), a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data; and

determine whether the communication device (120, 730, 1000, 1100) is successfully authenticated or not at least partially based on the response message.
The authentication server (125, 715, 725, 1000, 1200) of claim 48, wherein the instructions (1010), when executed by the processor (1006), further cause the processor (1006) to perform the method (900) of any of claims 26 to 47.
An authentication server (125, 715, 725, 1000, 1200) adapted to:

transmit, to a communication device (120, 730, 1000, 1100), a request message for requesting at least one of multiple pieces of data, the multiple pieces of data being communicated by the communication device (120, 730, 1000, 1100) and stored in a database which is accessible to the authentication server (125, 715, 725, 1000, 1200);

receive, from the communication device (120, 730, 1000, 1100), a response message comprising the at least one piece of data which is requested and/or data uniquely identifying the at least one piece of data; and

determine whether the communication device (120, 730, 1000, 1100) is successfully authenticated or not at least partially based on the response message.
The authentication server (125, 715, 725, 1000, 1200) of claim 50, wherein the communication device (120, 730, 1000, 1100) is further adapted to perform the method (900) of any of claims 26 to 47.
A computer program (1010) comprising instructions which, when executed by at least one processor (1006), cause the at least one processor (1006) to carry out the method (800, 900) of any of claims 1 to 20 and 25 to 47.
A carrier (1008) containing the computer program (1010) of claim 52, wherein the carrier (1008) is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.
A system (10, 70) for authentication, the system (10, 70) comprising:

one or more communication devices (120, 730, 1000, 1100) of any of claims 21 to 24; and

at least one authentication server (125, 715, 725, 1000, 1200) of any of claim 48 to 51.