BACKGROUND

[0001] A device, such as a printing device, may be equipped with a capability erf transmitting beacons. The beacons indude device specific information, such as a unique identifier of the device, for being shared with personal mobile devices of users. Based cm the unique identifier, the users may establish a session with the device to execute a command sent by the personal mobile devices of foe users.

BRIEF DESCRIPTION OF FIGURES

[0002] The detailed description is provided with reference to the accompanying figures, wherein:

[0003] FIG. 1 illustrates an electronic device, according to an example;

[0004] FIG. 2 illustrates an example of a network environment employing the electronic device, according to an example;

[0005] FIGS. 3A-3D illustrate call flow diagrams for device validation using tokens, according to an example;

[0006] FIG. 4 illustrates a method for device validation using tokens, according to an example; and

ΐoooh FIG. 5 illustrates a non-transitory computer readable medium for device validation using tokens, according to an example.

DETAILED DESCRIPTION

[0008] Beacons are used for transmitting data over short distances via radio waves. The beacons are advertised or broadcasted for being discovered by user devices, such as srhartphones, mobile phones. When a user walks past a device broadcasting the beacons, a beacon sends a code, such as an identifier of the device, to a user device. The code may be read by an application, such as a third-party explication installed on the user device to communicate or establish a session with the device broadcasting the beacon.

[0009] As the beacons are public advertisements, the beacons once discovered may be recorded and reused to deceive a user device in an attempt to maliciously collect data from the users. Alternatively, the beacons may also be anticipated and may be used to attack devices in a cloud environment. Thus, tiie beacons may cause the unintended users from stealing users’ content.

[0010] The present subject matter discloses approaches for protecting users’ content from unintended users, by including a device signature in a token transmitted by an electronic device, such as a printer. The token is rotated at a fixed time interval such that a frequency of rotation of the token is different from a frequency of rotation of the device signature. In an example, tiie device signature may be signed by a time-stamp of the electronic device. As the token includes the time-stamp of the electronic device, the rotatable token cannot be re-used by the unintended users.

[0011] In various implementations, the present subject matter describes approaches for validating an electronic device based on tokens. In an example, a token may be a data packet that may be transmitted by an electronic device, such as the printer.†he electronic device may generate the token that may be specific to the electronic device which is to be validated. The token includes a unique identifier of the electronic device, the device signature, and the time- stamp of the electronic device. The device signature may indude a cryptographic key or a random value. In an example, the cryptographic key is exchanged between the electronic device and an authentication server, when tiie electronic device registers with the authentication server. Further, the random value may be generated by the electronic device.

[0012] The electronic device shares tiie token with multiple uses ^* devices, either through short range communication technologies or through wide range communication technologies. The token is rotated at a fixed time interval. For example, upon expiry of the fixed time interval, the token is modified and re-shared with the user devices. The inclusion of the device signature ensures that the token cannot be reused by anyone. Upon receiving the token, a user device may communicate with the electronic device using the token. For example, the user device may send a transaction request to the electronic device. The transaction request may indude a command to be executed by the electronic device and the token.

[0013] In an implementation, the transaction request may be received by the electronic device or by a doud server assodated with the electronic device. In case the user device sends the transaction request directly to the electronic device, the electronic device may validate the token based on a comparison between the device signature retrieved from toe transaction request and the device signature stored in toe electronic device. Upon successful validation of toe token, the electronic device may execute toe command induded within the transaction request.

[0014] In another implementation, when the transaction request is shared with the cloud servo', the cloud server may validate toe token based on comparison of the device signature retrieved from the transaction request and toe device signature stored by the authentication server. Upon successful validation of the token, the doud server may either execute toe command or may forward the command contained in the transaction request to the electronic device for execution. Accordingly, toe device signature fadlitates in securing an identity of toe electronic device against misuse.

[0015] The present subject matter is further described with reference to toe accompanying figures. Wherever possible, the seme reference numerals are used in the figures and toe following description to refer to toe same or similar parts. It should be noted that the description and figures merely illustrate principles of the present subject matter. It is thus understood that various arrangements may be devised that, although not explicitly described or shown herein, encompass the principles of the present subject matter. Moreover, all statements herein reciting principles, aspects, and examples of toe present subject matter, as well as specific examples thereof, are intended to encompass equivalents thereof.

[0016] The manner in which the tokens are used for validating identity of an electronic device is implemented are explained in detail with respect to FIGS. 1-5, While aspects of described electronic device can be implemented in any number of different computing systems, environments, and/or implementations, the examples are described in toe context of the following device(s).

[0017] FIG. 1 illustrates an electronic device 100, according to an example. The electronic device 100 may include, for example, engines 102. The engines 102, amongst other things, indude routines, programs, objects, components, and data structures, which perform particular tasks or implement particular abstract data types. The engines 102 may also be implemented as, signal processor^), state machine(s), logic tircuitries, and/or any other device or component that manipulates signals based on operational instructions. Further, the engines 102 can be implemented by hardware, by computer- readable instructions executed by a processing unit, or by a combination thereof.

[0018] The engines 102 may indude a token generation engine 104 that may generate a token for the electronic device 100. The token may be based on a universal unique identifier (UUID) of toe electronic device 100, a device signature, and a time-stamp of the electronic device 100. In an example* the device signature may indude a cryptographic key. When toe token indudes the cryptographic key, toe token may be referred to as Mode 0 token, in another example, the device signature may be a random value that may be generated by the electronic device 100. When the token indudes toe random value, the token may be referred to as Mode 1 token. In an example, toe time-stamp may be inserted in the device signature of both the Mode 0 and Mode 1 tokens. In another example, toe time-stamp may be inserted in the device signature of toe Mode 0 token. In this case, the Mode 1 token may indude any contextual data that may indicate which random value is being used in toe token.

[0019] Further, the token generation engine 104 may periodically share toe token with various user devices (not shown). For example, the token may be shared for a fixed time duration, such as 8 seconds. After completion of the fixed time duration, toe token may be re-generated and shared again. The periodic sharing of the token, in modified or regenerated form, ensures that the same token cannot be used again for carrying out transactions with toe electronic device 100. In an example, a frequency of rotation of the token may be different from a frequency of rotation of toe device signature. Referring to toe above example, toe frequency of rotation of the token may be 8 seconds, 10 seconds, and so on, and the frequency of rotation of the device signature may be 1 min, 5 mins, 5 hours, 1 day, and so on.

[0020] According to an example, the engines 102 may include an execution engine 106 that may execute the command received from a user device upon successful validation of the token. In the present example, the token may be validated either by the electronic device 100 or by a cloud server (not shown). For example, toe electronic device 100 may maintain a list of shared tokens and validate the token received from the user device with a recently generated token in the list of shared tokens. Upon successful validation of toe token, the cbmmahd included in toe transaction request may be executed by the execution engine 106. In case the token is not validated successfully, the command may be rejected and the user device may have to receive a new token from the electronic device 100 to communicate with the electronic device 100. As the token generated based on the device signature is specific to the electronic device 100, the token may not be reproduced by outside parties. Thereby, the tokens facilitate in authenticating tire identity of the electronic device 100 and protecting users' content from being misused. A manner by which the tokens are used to validate the electronic device 100 is explained with respect to FIG. 2.

[0021] FIG. 2 illustrates a network environment 200 employing the electronic device 100. Examples of the electronic device 100 may include, but are not limited to, a printer, a scanner, multi-function printer, and so on. The electronic device 100 may communicate with a plurality of user devices, such as 202-1 , 202-2. 202-N, collectively referred to as user devices 202 and individually referred to as a user device 202. In an example, the user devices 202 can be potable and can be of different types. For instance, the user devices 202 can be a mobile phone, a laptop, a smartphone, or the like.

[0022] The network environment 200 may also include an authentication server 204 in communication with the electronic device 100. In an example, the electronic device 100 may be registered with the authentication server 204. Based on the registration, the authentication server 204 and the electronic device 100 may exchange the device signature, such as a cryptographic key, over a key agreement protocol (KPA).

[0023] Further, the electronic device 100 may be in communication with a cloud server 206. The cloud server 206 may provide cloud services to transact with any web-connected electronic device by routing commands from tiie user devices 202 to the web-connected electronic device. In an example implementation, the doud server 206 may be time synchronized with the electronic device 100. The time synchronization may prevent any drift in timings of the cloud server 206 and the electronic device 100. For instance, a dock of the electronic device 100 and the cloud server 206 may be synchronized with each other to reflect the time starting from a reference dock. The time synchronization between the doud server 206 and the electronic device 100 facilitates in («eventing malicious users to steal users ^* content by validating transaction requests received from the user devices 202. The doud server 206 fatiiitates in validating the transaction requests received from the user devices 202. The doud server 206 may be authorized by the authentication server 204 to validate the transaction requests for the electronic device 100.

[0024] According to an example, the electronic device 100 may communicate with the user devices 202, the authentication server 204, and the doud server 206 over a communication network 208. The communication network 208 may be a wireless network, a wired network, or a combination thereof. The communication network 208 can also be an individual network or a collection of many such individual networks, interconnected with each other and functioning as a single large network, e.g., the Internet or an intranet. The communication network 208 can be employed as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and such. The communication network 208 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocoi/lntemet Protocol (TCP/IP), etc., to communicate with each other. Further, the communication network 208 may include network devices, such as network switches, hubs, routers, for providing a link between foe electronic device 100 and the user devices 202 or the authentication server 204 or foe cloud server 206. The network devices Within foe communication network 208 may interact with the electronic device 100, foe user devices 202, the authentication server 204, and foe cloud server 206, through foe communication links. [0025] in one example, the electronic device 100 includes a processor 210 and a memory 212 coupled to the processor 210. The processor 210 may include microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any other devices that manipulate signals and date based on computer- readable instructions. Further, functions of the various elements shown in the figures, including any functional blocks labelled as“processors)", may be provided through the use of dedicated hardware as well as hardware capable of executing computer-readable instructions.

[0028] The memory 212, communicatively coupled to the processor 210, can include any non-transitory computer-readable medium known in the art including, for example, volatile memory, such as static random-access memory (SRAM) and dynamic random-access memory (DRAM), arid/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.

[002h The electronic device 100 also includes an interface 214. The interface 214 may include a variety of interfaces, for example, interfaces 214 for user devices 202. The interface 214 may include date output devices. The interface 214 facilitates communication between the electronic device 100 and various communication and computing devices and various communication networks, such as networks that use a variety of protocols, for example, Real Time Streaming Protocol (RTSP), Hypertext Transfer Protocol (HTTP), Live Streaming (HLS) and Real-time Transport Protocol (RTP).

[0028] Further, as described with reference to FIG. 1, the electronic device 100 includes engines 102. In one example, the engines 102 include an authentication engine 216, the token generation engine 104, tire execution engine 106, and other engines) 218. The other engtne(s) 218 may include programs or coded instructions that supplement the applications or functions performed by the electronic device 100. The engines 102 may be implemented as described in relation to FIGS. 1 and 2.

[0029] in an example, the electronic device 100 includes data 220. The data 220 may include an authentication data 222, a token data 224, and other data 226. The other data 226 may include data generated and saved by the engines 102 for implementing various functionalities of the electronic device

100.

[0030] As explained previously, the tokens generated by the electronic device 100 includes the device signature which facilitates in validating the identity of the electronic device 100. In an example implementation, to generate Mode 0 tokens, the electronic device 100 may exchange the device signature, such as a cryptographic key, with the authentication server 204. To do so, the authentication engine 216 of the electronic device 100 may register the electronic device 100 with the authentication server 204. In an example, the authentication engine 216 may share an authentication certificate of the electronic device 100 with the authentication sarver 204. For example, the authentication engine 216 may share an authentication certificate of the electronic device 100 with the authentication server 204. The authentication certificate is an electronic document that identifies the electronic device 100 and associates an identity, such as the UUID of the electronic device 100 with a public key. In addition to the public key, the authentication certificate includes a name of the electronic device 100, an expiration date of the authentication certificate, a name of an issuing authority, and so on.

[0031] Based on the information in the authentication certificate, the authentication server 204 may generate a set of one-time cryptographic keys for the electronic device 100. In an example, the authentication server 204 may store the set of one-time cryptographic keys in a database associated with the authentication server 204. For instance, the database may be a key management system. Further, the authentication server 204 and the electronic device 100 may exchange a cryptographic key from the set of one-time cryptographic keys over a key agreement protocol (KPA). Examples of the KPA include, but are not limited to, Diffie-Hellman (DH) key exchange and Rivest- Shamir-Adleman (RSA) key exchange mechanism (RSA-KEM).

[0032] In another example implementation, to generate Mode 1 tokens, tiie authentication engine 216 may generate the device signature, such as a random value, for the electronic device 100. In an example, the authentication engine 216 may employ a Pseudo Random Number Generator (PRNG) or a Cryptographically Secure Random Number Generator (CSRNG), to generate tiie random value. The authentication engine 216 may store the set of one-time cryptographic keys and a list of random values as the authentication data 222.

[0033] Further, the token generation engine 104 may generate a token (Mode 0 or Mode 1) for being transmitted by the electronic device 100. The token may be based cm a universal unique identifier (UUID) of the electronic device 100, the device signature, and a time-stamp of the electronic device 100. The device signature in the Mode 0 token may indude tire cryptographic key exchanged with the authentication server 204. The device signature in the Mode 1 token may indude the random value generated by the electronic device 100. In an example, the device signature may be embedded with the time- stamp of the electronic device 100. In another example, the time-stamp may be inserted in the device signature of the Mode 0 token. In this case, the Mode 1 token may indude any contextual data that may indicate which random value is being used in the token.

[0034] According to an example implementation, the token may have a length of about 20 bytes, in which about 16 bytes may be occupied by tile UUID of the electronic device 100. The occupancy of tire remaining four bytes of tire token may vary based on the device signature induded in the token. For example, in Mode-0, the remaining four bytes of toe token may indude a mode indicator, the cryptographic key, and toe time-stamp of the electronic device 100. An exemplary format of allocation of toe remaining 4 bytes of the token in Mode-0 is provided below:

[0035] The 'Mode* in toe above format is indicative of a type of the device signature in the token. In Mode-0, the 2 bits may have a value of Ό0’ indicating that a cryptographic key is used in toe token. Further, toe time-stamp of the electronic device 100 occupies 6 bits. Accordingly, toe Mode and time-stamp fields occupy 1 byte of the remaining 4 bytes of toe token. The 3 LSBs are occupied by the cryptographic key in the Mode 0 token.

[0036] In Mode-1, the remaining four bytes of toe token may indude a mode indicator, reserved bits, and toe random value as generated by the electronic device 100. An exemplary format of allocation of toe remaining 4 bytes of the token in Mode-1 is provided below:

[003h In Mode-1 , the 2 bits may have a value of '10'. Further, 6 bits may be reserved. In an example, the reserved bits may be used for a timestamp or any data that may identify which random value is used in toe token. Further, toe 3 LSBs are occupied by the random value in the token.

[0038] Further, toe token generation engine 104 may share toe token with tire user devices 202. In an example, tire token generation engine 104 may share the token with the user devices 202 over wide range communication technologies, such as Wi-Fi, Ethernet, wireless local area network (WLAN), and so on. Therefore, the user devices 202 may receive the token transmitted from the electronic device 100 even when the user devices 202 are not in a proximity of the electronic device 100. Further, while sharing the tokens over wide-range communication technologies, die token may not be broadcasted by the electronic device 100. In this case, to receive the token, the user devices 202 may said a request to the token generation engine 104.

[0039] In another example, the token generation engine 104 may share tiie tokens with the user devices 202 over short range communication technologies, such as Bluetooth®. In this example, the user devices 202 in proximity of the electronic device 100 may be able to receive the token. For short-range communication technologies, the token generation engine 104 may broadcast the token that may be detected by the user devices 202 proximal to the electronic device 100. Before sharing the token, the token generation engine 104 may store information pertaining to the remaining 4 bytes of the token as the token data 224.

[0040] In an example implementation, the token may be shared periodically with the user devices 202. Far example, the token generation engine 104 may transmit the token for a fixed or pre-determined time interval, such as 8 seconds, 10 seconds, and so on. After expiry of the fixed time interval, the token may be re-generated by the token generation engine 104 and shared again. In an aspect, a frequency of rotation of the token may be different from a frequency of rotation of the device signature in the token.

[0041] For example, in case of Mode 0 tokens, the cryptographic key may have a rotation frequency of about 15 mins and a rotation frequency of the Mode 0 token may be 10 seconds. Accordingly, the token generation engine 104 may re-share the Mode 0 token after every 10 seconds with the UU1D of the electronic device 100, the cryptographic key inserted with a new time stamp of the electronic device 100. After 15 mins, the token generation engine 104 may share the Mode 0 token with the UUID of the electronic device 100, a new cryptographic key inserted with a new time stamp of the electronic device 100. As the Mode 0 tokens involve cryptographic keys as the device signatures, the Mode 0 tokens ensure that the identity of the electronic device 100 is not compromised and a secure communication may be established between the electronic device 100 and the user devices 202.

[0042] In case of Mode 1 tokens, the device signature, i.e., random value may have a rotation frequency of about 5 mins and a rotation frequency of the Mode 1 token may be 5 seconds. Accordingly, the token generation engine 104 may re-share the Mode 1 token after every 5 seconds with the UUID of the electronic device 100, the random value inserted with a new time stamp of the electronic device 100. After 5 mins, the token generation engine 104 may share tiie Mode 1 token with the UUID of the electronic device 100 and a new random value. In addition, the Mode 1 token may indude the time-stamp of the electronic device 100 or any data that may provide an indication about the random value being used in the Mode 1 token.

[0043] The user devices 202 may receive the tokens being shared by the token generation engine 104. In an example, the tokens (Mode 0 or Mode 1) may be broadcasted by the token generation engine 104 for being detected by the user devices 202. The tokens may be broadcasted over the short-range communication technologies. For instance, the user devices 202 may detect tiie broadcasted tokens over Bluetooth®. In another example, the user devices 202 may request the electronic device 100 to share the token, such as over Wi-Fi.

[0044] Upon receiving the token, the user devices 202 may communicate with the electronic device 100. For example, the user devices 202 may send a transaction request to the electronic device 100 based on the token received from the electronic device 100. The transaction request may indude a command for being executed by the electronic device 100 and the token as received by the user device 202.

[0045] In an example, the user device 202 may send toe transaction requests directly to the electronic device 100. For example, toe user device 202 may send a print command along with the token to the electronic device 100. Upon receiving the transaction request, the execution engine 106 of toe electronic device 100 may compare toe token received from the user device 202 with toe token data 224. For example, toe execution engine 106 may compare toe device signature mentioned in the token (Mode 0 or Mode 1) with a list of recently shared tokens that were shared by the eledronic device 100. If the device signature matches a recently shared device signature from the list, the execution engine 106 may validate toe token. In an example, the execution engine 106 may also compare the time-stamp associated with the tokens.

[0046] Upon successful validation of the token, the execution engine 106 may execute the print command as per the transaction request In an example, to complete the print command, a user of the user device 202 may or may not have to provide input, such as pressing a key, on the electronic device 100.

[004h In another example, the user device 202 may send the transaction request to the cloud server 206 for validation of the token in the transaction request. For example, the transaction request received from the user device 202 may include a command to scan and stare a document to a user's cloud storage. In case of Mode-0 token, the doud server 206 may, in order to validate the Mode-0 token, query the authentication server 204 to access the limited set of one-time cryptographic keys generated for the electronic device 100. The cloud server 206 may then compare the cryptographic key in the token received from the user device 202 with the limited set of one-time cryptographic keys. Upon successful validation, the cloud server 206 may route the scan and store command to the electronic device 100 for execution by the execution engine 106. Alternatively, the cloud server 206 may execute the command as sent by the user device 202.

[0048] In case of Mode-1 token, the cloud server 206 may query the electronic device 100 to check validity of the token. The electronic device 100 may compare the random value included in the token received from the user device 202 with the list of random values generated for the electronic device 100. The electronic device 100 may provide a response of the comparison to the cloud server 206. Upon successful validation, the cloud server 206 may route the scan and store command to the electronic device 100 for execution by tiie execution engine 106. Alternatively, the cloud server 206 may execute tiie command. Due to the validation of the tokens, Mode-0 as well as Mode-1 , tiie identity of the electronic device 100 is validated. Accordingly, it may be ensured that tiie data received from the user devices 202 is not going to unintended users.

[0049] FIGS. 3A-3D illustrate call flow diagrams 300, 320, 340, and 360 for device validation using tokens, according to an example of the present subject matter. The various arrow indicators used in the call-flow diagrams 300, 320, 340, and 360 depict the transfer of data between the various entities in the network environment 200 and between the electronic device 100, the user device 202, the authentication server 204, and the cloud server 206. Although tiie description of FIGS. 3A-3D has been made in considerable detail with respect to the communication network 208, it will be understood that the steps for device validation using tokens can be implemented in other networks as well, albeit with lew alterations. Further, certain trivial steps have bean omitted in the sequence diagrams, for the sake of brevity and clarity. [0050] Referring to FIG. 3A, the device validation may be performed by the electronic device 100 based on a cryptographic key. At step 302, the electronic device 100 may obtain a device signature. The device signature may include a cryptographic key exchanged with an authentication server 204. To receive the cryptographic key, the electronic device 100 may send a registration request to the authentication server 204.

[0051] In an example, the electronic device 100 may send an authentication certificate for the electronic device 100 in foe registration request. The authentication certificate is an electronic document that identifies the electronic device 100 and associates an identity, such as a universal unique identifier (UUID) of the electronic device 100 with a public key. The authentication server 204 may, based cm foe information of the authentication certificate, generate a limited set of one-time cryptographic keys for the electronic device 100. The authentication server 204 may store the set of onetime cryptographic keys in a database associated with foe authentication server 204. Further, the authentication server 204 and tine electronic device 100 may exchange a cryptographic key from the set of one-time cryptographic keys over a key agreement protocol (KPA).

[0052] At step 304, the electronic device 100 may generate a Mode 0 token based on a unique identifier of the electronic device 100, the device signature, and a time-stamp of the electronic device 100. As mentioned above, when the token includes the unique identifier of the electronic device 100 and toe cryptographic key, the token is considered as Mode 0 token. In case of Mode 0 tokens, the cryptographic key is signed with a time-stamp of the electronic device 100.

[0053] At step 306, foe electronic device 100 may add the Mode 0 token to a list of recently generated tokens in an internal memory of the electronic device 100. [0054] Further, at step 308, the electronic device 100 may share the Mode 0 token with the user device 202. The Mode 0 token may be shared over short-range communication technologies or wide-range communication technologies.

[0055] At step 210, the electronic device 100 may receive a transaction request from toe user device 202. In an example, toe transaction request may include a command to be executed and the Mode 0 token.

[0056] At step 312, the electronic device 100 may validate toe Mode 0 token by comparing the Mode 0 token received from toe user device 202 with toe list of recently shared tokens stored locally in the electronic device 100. The electronic device 100 may communicate with the user device 202 to provide a response of toe comparison.

[005h At step 314, the electronic device 100 may upon successful validation of toe Mode 0 token, execute the command as per toe transaction request.

[0058] Referring to FIG. 3B, the device validation may be performed by the electronic device 100 based on a random value. At step 322, toe electronic deyice 100 may obtain a device signature. The device signature may include a random value generated by the electronic device 100. In an example, the authentication engine 216 may employ a Pseudo Random Number Generator (PRNG) or a Cryptographically Secure Random Number Generator (CSRNG), to generate toe random value.

[0059] At step 324, the electronic device 100 may generate a Mode 1 token based cm a unique identifier of the electronic device 100, toe device signature, and a time-stamp of toe electronic device 100 or any data that may provide ah indication about toe fahdom value being used in toe Mode 1 token. As mentioned above, when the token includes toe unique identifier of the electronic device 100 and tha random value, the token is considered as Mode 1 token.

[0060] At step 326, die electronic device 100 may add die Mode 1 token to a list of recently generated tokens in an internal memory of die electronic device 100.

[0061] Further, at step 328, the electronic device 100 may share die Mode 1 token with the user device 202. The Mode 1 token may be shared over short-range communication technologies or wide-range communication technologies.

[0062] At step 330, the electronic device 100 may receive a transaction request from the user device 202. In an example, die transaction request may include a command to be executed and the Mode 1 token.

[0063] At step 332, the electronic device 100 may validate the Mode 1 token by comparing the Mode 1 token received from the user device 202 with die list of recentiy shared tokens stored locally in the electronic device 100. The electronic device 100 may communicate with the user device 202 to provide a response of the comparison.

[0064] At step 334, the electronic device 100 may upon successful validation of the Mode 1 token, execute the command as per the transaction request.

[0065] Now referring to FIG. 3C, the device validation may be performed by the cloud server 206. At step 342, the electronic device 100 may obtain a device signature. The device signature may include a cryptographic key exchanged with the authentication server 204. To receive the cryptographic key, the electronic device 100 may send a registration request to the authentication server 204. [0066] At step 344, the electronic device 100 may generate a Mode 0 token based on a unique identifier of the electronic device 100, the device signature, and a time-stamp of the electronic device 100.

[0067] At step 346, tiie electronic device 100 may add the Mode 0 token to a list of recently generated tokens in an internal memory of the electronic device 100.

[0068] Further, at step 348, the electronic device 100 may share the Mode 0 token with the user device 202. The Mode 0 token may be shared over short-range communication technologies or wide-range communication technologies.

[0069] At step 350, the user device 202 may send tiie transaction request to the cloud server 206. As explained with respect to FIG. 2, the doud server 206 may be time synchronized with the electronic device 100. The time synchronization may prevent any drift in timings of the doud server 206 and tiie electronic device 100. Thus, the clock of the doud server 206 and the electronic device 100 may have the same time.

[0070] To validate the token, the doud server 206 may request the authentication server 204 to check if the device signature of the Mode 0 token is present in a list of recently shared device signatures. In an example, the list of recently shared device signatures indudes the limited set of one-time cryptographic keys, as depicted in step 352. In an example, the doud server 206 may query the list of recently shared device signatures from the authentication server 204. The cloud server 206 may then compare tiie device signature to validate the token. For example, the doud server 206 may compare tiie time-stamp on the cryptographic key with the time-stamp of the doud server 206. As the doud server 206 and the electronic device 100 are time synchronized, the time-stamp of the doud server 206 and the electronic device 100 is same. Further, the doud server 206 may compare the cryptographic key in the Mode 0 token with the fist of cryptographic keys exchanged with foe authentication server 204.

[0071] At step 354, the authentication server 204 may acknowledge the validity of the Mode 0 token to the doud server 206, based on comparison of the device signatures.

[0072] At step 356, the doud server 206 may upon successful validation of the Mode 0 token, execute the command as per the transaction request and provide an output to foe user device 202. Alternatively, foe doud server 206 may route foe command to the electronic device 100 for execution.

[0073] Now referring to FIG. 30, the device validation may be performed by foe doud server 206 based on a random value. At step 362, foe electronic device 100 may obtain a device signature. The device signature may indude a random value generated by the electronic device 100.

[0074] At step 364, the electronic device 100 may generate a Mode 1 token based cm a unique identifier of foe electronic device 100, the device signature, and a time-stamp of the electronic device 100 or any data that may provide an indication about foe random value being used in foe Mode 1 token.

£00753 At step 366, foe electronic device 100 may add the Mode 1 token to a list of recently generated tokens in an internal memory of the electronic device 100. Further, at step 368, the electronic device 100 may share the Mode 1 token with the user device 202.

[0076] At step 370, the user device 202 may send the transaction request to the doud server 206. In addition, at step 372, foe doud server 206 may query the electronic device 100 to check a validity of foe Mode 1 token received from the user device 202. In an example, to validate foe token, foe doud server 206 may request the electronic device 100 to check if foe device signature of foe Mode 1 token is present in a list of recently shared device signatures. In an example, the list of recently shared device signatures indudes the random values generated by the electronic device 100. In another example, the cloud server 206 may query the list of recently shared device signatures from the electronic device 100. The cloud server 206 may then compare the device signature to validate the Mode 1 token. For instance, die cloud server 206 may compare the random value in the Mode 1 token with the list of random values generated by the electronic device 100.

[0077] At step 374, the electronic device 100 may acknowledge the validity of the Mode 1 token to the cloud server 206, based on comparison of die device signatures.

[0078] At step 376, die cloud server 206 may upon successful validation of the Mode 1 token, execute the command as per die transaction request and provide an output to die user device 202. Alternatively, the doud server 206 may route die command to the electronic device 100 for execution.

[0079] FIG. 4 illustrates a method 400 for device validation based on tokens, according to an example of the present subject matter. The method 400 may be described in the general context of computer executable instructions. The method 500 can be implemented by processors) or device(s) through any suitable hardware, a non-transitory machine readable medium, or a combination thereof. Further, although the method 400 is described in context of a device that is similar to die electronic device 100, other suitable devices or systems may be used for execution of the method 400.

[0080] The order in which the method 400 is described is not intended to be construed as a limitation, and any number of the described method blocks may be combined in any order to implement the method 400, or an alternative method. In some example, blocks of the method 400 may be executed based on instructions stored in a non-transitory computer-readable medium. The non- transitory computer-readable medium may include, for example, digital memories, magnetic storage media, such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.

[0081] Referring to FIG. 4, at block 402, a token may be generated by an electronic device, such as the electronic device 100. The token may be based on a unique identifier of the electronic device 100, a device signature, and a time-stamp of the electronic device 100. The device signature may include a cryptographic key exchanged with an authentication server 204 or a random value generated by the electronic device 100. In an example implementation, the token may be generated by the token generation engine 104.

[0082] At block 404, the token is shared with a user device 202. Based on the token, the user device 202 may establish a session with the electronic device 100. The token may be rotated at a fixed time interval. In an example, the token may be modified and shared again after about every 10 seconds. In an example implementation, the token generation engine 104 may share the token with the user device 202. Based on the shared token, the user device 202 may share a transaction request to the electronic device 100 or to the cloud server 206, The transaction request may include a command to be executed and the token received from the electronic device 100.

[0083] At block 406, the electronic device 100 may execute a command received from the user device 202. The command is to be executed upon successful validation of the token. In an example, the validation of the token may be performed by tine electronic device 100 or by tee doud server 206, In case of the validation by the doud server 206, the doud server 206 may forward the command to a respective electronic device based on the unique identifier of the electronic device contained in the token, in an example implementation, the execution engine 106 may execute the command received from the user device 202 based on the successful validation of the token. [0084] FIG. 5 illustrates an example network environment 500 using a non-transitory computer readable medium 502 for device authentication based on tokens, according to an example of the present subject matte’. The network environment 500 may be a public networking environment or a private networking environment. In one example, the network environment 500 includes a processing resource 504 communicatively coupled to the non- transitory computer readable medium 502 through a communication link 506. For example, toe processing resource 504 may be a processor of a computing system, such as toe electronic device 100, for fetching and executing computer-readable instructions from the non-transitory computer-readable medium 502.

[0085] The non-transitory computer readable medium 502 may be, for example, an internal memory device or an external memory device. In one example, the communication link 506 may be a direct communication link, such as one formed through a memory read/write interface. In another example, the communication link 506 may be an indirect communication link, such as one formed through a network interface. In such a case, the processing resource 504 may access the non-transitory computer readable medium 502 through a network 508. The network 508 may be a single network or a combination of multiple networks and may use a variety of communication protocols.

[0086] The processing resource 504 and the non-transitory computer readable medium 502 may also be communicatively coupled to data sources 510 over the network 508. The data sources 510 may include, for example, databases and computing devices. The data sources 510 may be used by the database administrators and other users to communicate with the processing resource 504.

[0087] In one example, toe non-transitory computer readable medium 502 includes a set of computer readable and executable instructions for device authentication based on tokens. The set of computer-readable instructions may indude instructions as explained in conjunction with FIGS. 1 and 2. The set of computer readable instructions, referred to as instructions hereinafter, may be accessed by the processing resource 504 through the communication link 506 and subsequently executed to perform acts for device authentication based on tokens.

[0088] Referring to FIG. 5, in an example, toe non-transitory computer- readable medium 502 may indude instructions 512 to obtain a device signature for toe electronic device 100. In an example, the device signature may indude a cryptographic key received from an authentication server or a random value generated by the electronic device 100. Further, toe non-transitory computer- readable medium 502 may indude instructions 514 to generate a token based on a unique identifier of the electronic device 100, toe device signature, and a time-stamp of the electronic device 100. The non-transitory computer-readable medium 502 may also indude instructions 516 to share the token with a user device 202 to establish a session. The token is rotated at a fixed time interval. In an example, a frequency of rotation of the token is different from a frequency of rotation of toe device signature.

[0089] The non-transitory computer-readable medium 502 may include instructions 518 to execute a command received from the user device upon successful validation of the token. In an example, the non-transitory computer- readable medium 502 may indude instructions to receive an indication of validation of toe token from a doud server associated with toe electronic device 100. In an alternative example, toe toe non-transitory computer-readable medium 502 may cause the processor to validate toe token.

[0090] Although aspects for the present disdosure have been described in a language specific to structural features and/or methods, it is to foe understood that the appended daims are not limited to the specific features or methods described herein. Rather, the specific features and methods are disclosed as examples of die present disclosure.