DESC:RESERVATION OF RIGHTS
[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as but are not limited to, copyright, design, trademark, integrated circuit (IC) layout design, and/or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.

FIELD OF INVENTION
[0002] The embodiments of the present disclosure generally relate to systems and methods for providing authentication and data security for Internet of Things (IoT) devices. More particularly, the present disclosure relates to a system and a method for authentication and data security of IoT devices communicating on radio.

BACKGROUND
[0003] The following description of the related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section is used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of the prior art.
[0004] Internet of things (IoT) is a vast network of connected physical objects that exchange data with other devices and systems via the internet. Security of the IoT network is critical as usage of these networks is becoming vulnerable to highly-targeted attacks. Securing the IoT network from a malicious access requires ensuring that infected IoT devices do not act as a gateway in other sub-networks of the network leading to leakage of sensitive information and malicious attacks. Typically, security infrastructure needs to be scalable for a network of IoT Edge devices and central gateway devices. However, available security mechanisms for Bluetooth Enabled (BLE-enabled) IoT devices, like pairing, are not scalable enough. Further, centralized device management is not easily achievable through a pairing mechanism.
[0005] There is, therefore, a need in the art to provide a system and a method that can mitigate the challenges associated with the prior art(s).

OBJECTS OF THE INVENTION
[0006] Some of the objects of the present disclosure, which at least one embodiment herein satisfies are listed herein below.
[0007] It is an object of the present disclosure to provide a system and a method for authenticating a gateway via an Internet of Things (IoT) device.
[0008] It is an object of the present disclosure to provide a system and a method where whitelisting control is distributed between the IoT device and gateways offering protection against malicious attacks.
[0009] It is an object of the present disclosure to provide a system and a method that enables authentication and data security for IoT devices.
[0010] It is an object of the present disclosure to provide a system and a method that uses an authentication protocol for IoT devices communicating over radio.
[0011] It is an object of the present disclosure to a system and a method that provides onboarding of IoT devices through a secure channel design.
[0012] It is an object of the present disclosure to provide a system and a method where a secure communication channel design is created for a large number of IoT devices.

SUMMARY
[0013] This section is provided to introduce certain objects and aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.
[0014] In an aspect, the present disclosure relates to a system for authentication and data security of devices. The system includes a processor, and a memory operatively coupled with the processor, where said memory stores instructions which, when executed by the processor, cause the processor to transmit an onboarding request to a cloud server and receive an account token in response to the onboarding request. The processor establishes one or more configurations with the cloud server based on the account token. The processor receives one or more whitelist updates associated with one or more devices from the cloud server based on the account token and the one or more configurations. The processor transmits the account token to the one or more devices. The processor receives an authentication problem from the one or more devices based on the account token, wherein the authentication problem is encrypted with a device token. The processor transmits an authentication solution to the one or more devices based on the authentication problem. The authentication solution is encrypted with the device token. The processor determines if a match exists between the authentication problem and the authentication solution. The processor, in response to a positive determination, transmits a data transfer request to the one or more devices. The processor receives encrypted data from the one or more devices for a predetermined period based on the data transfer request and transmits the encrypted data to the cloud server.
[0015] In an embodiment, in response to a negative determination, the processor may terminate the data transfer request associated with the one or more devices.
[0016] In an embodiment, the device token may be encrypted using an Advanced Encryption Standard (AES) 128 technique based on an identifier and the account token associated with the one or more devices.
[0017] In an embodiment, the encrypted data may be encrypted using a nonce and a device key.
[0018] In an embodiment, the nonce may be determined by the processor for the predetermined period using a device identifier (ID) associated with the one or more devices and the device token.
[0019] In an embodiment, the processor may receive a renewal token from the cloud server upon an expiry of the predetermined period to establish one or more updated configurations with the cloud server and receive one or more updated whitelist updates associated with the one or more devices.
[0020] In an aspect, the present disclosure relates to a method for authentication and data security of devices. The method includes transmitting, by a processor associated with a system, an onboarding request to a cloud server, and receiving, by the processor, an account token in response to the onboarding request. The method includes establishing, by the processor, one or more configurations with the cloud server based on the account token. The method includes receiving, by the processor, one or more whitelist updates associated with one or more devices from the cloud server based on the account token and the one or more configurations. The method includes transmitting, by the processor, the account token to the one or more devices. The method includes receiving, by the processor, an authentication problem from the one or more devices based on the account token, wherein the authentication problem is encrypted with a device token. The method includes transmitting, by the processor, an authentication solution to the one or more devices based on the authentication problem, where the authentication solution is encrypted with the device token. The method includes determining, by the processor, if a match exists between the authentication problem and the authentication solution. The method includes, in response to a positive determination, transmitting by the processor, a data transfer request to the one or more devices. The method includes receiving, by the processor, encrypted data from the one or more devices for a predetermined period based on the data transfer request, and transmitting the encrypted data to the cloud server.
[0021] In an embodiment, the method may include terminating, by the processor, in response to a negative determination, the data transfer request to the one or more devices.
[0022] In an embodiment, the method may include encrypting, by the processor, the received device token using an AES 128 technique based on an identifier and the account token associated with the one or more devices.
[0023] In an embodiment, wherein the encrypted data may be encrypted using a nonce and a device key.
[0024] In an embodiment, the method may include determining, by the processor, the nonce for the predetermined period using a device ID associated with the one or more devices and the device token.
[0025] In an embodiment, the method may include receiving, by the processor, a renewal token from the cloud server upon an expiry of the predetermined period for establishing one or more updated configurations with the cloud server and receiving one or more updated whitelist updates associated with the one or more devices.

BRIEF DESCRIPTION OF DRAWINGS
[0026] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes the disclosure of electrical components, electronic components, or circuitry commonly used to implement such components.
[0027] FIG. 1 illustrates an example network topology (100) of a proposed system (104), in accordance with an embodiment of the present disclosure.
[0028] FIG. 2 illustrates an example block diagram (200) of a proposed system (104), in accordance with an embodiment of the present disclosure.
[0029] FIG. 3 illustrates an example flow diagram (300) of data flow associated with the proposed system (104), in accordance with an embodiment of the present disclosure.
[0030] FIG. 4 illustrates an example token renewal process (400) associated with the proposed system (104), in accordance with an embodiment of the present disclosure.
[0031] FIG. 5 illustrates an example computer system (500) in which or with which embodiments of the present disclosure may be implemented.
[0032] The foregoing shall be more apparent from the following more detailed description of the disclosure.

DEATILED DESCRIPTION
[0033] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address all of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein.
[0034] The ensuing description provides exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.
[0035] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail to avoid obscuring the embodiments.
[0036] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0037] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising” as an open transition word without precluding any additional or other elements.
[0038] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0039] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.
[0040] The present disclosure provides an authentication protocol for Internet of Things (IoT) devices communicating over radio. An account token based IoT device management is provided where whitelisting control is distributed between IoT devices and gateways offering protection against malicious attacks. The IoT device onboarding is provided through a secure channel design that enables data transfer from one or more IoT devices to a cloud server via a gateway. Further, the gateway is authenticated by the IoT devices for preventing malicious attacks during the data transfer process.
[0041] Various embodiments of the present disclosure will be explained in detail with reference to FIGs. 1-5.
[0042] FIG. 1 illustrates an example network topology (100) of a proposed system (104), in accordance with an embodiment of the present disclosure.
[0043] As illustrated in FIG. 1, in an embodiment, the IoT system may be broadly include three components, namely IoT Edge Device (102), a gateway device (104) (e.g., a system), and cloud server (106). The IoT edge device (102) may be compact computing device that is equipped, either Bluetooth or near field communication (NFC) to sense and collect data. Further, the IoT edge device (102) may process the data and submit the data to the cloud server (106) via the gateway (104). The IoT edge device (102) may communicate with the gateway (104) over radio. In an embodiment, the gateway (104) may transmit information to and fro between the cloud server (106) and the IoT edge device (102). The gateway (104) may include a gateway listener (108) and a gateway host (110). The gateway (104) may collect data coming from the IoT edge device (102), parse the data, and store the data in a specific format in a cache memory. The gateway (104) may then publish the stored data periodically to the cloud server (106) upon availability of a network. The cloud server (106) may process the received data and uses machine learning to process and extract valuable information from the data.
[0044] In an embodiment, the gateway (104) may be interchangeably referred as a system (104) throughout the disclosure. In an embodiment, the system (104) may transmit an onboarding request to the cloud server (106) and receive an account token in response to the onboarding request. The cloud server (106) may include one or more whitelist updates associated with the one or more devices (102). The system (104) may establish one or more configurations with the cloud server (106) based on the account token. The system (104) may receive the one or more whitelist updates associated with one or more devices (102) from the cloud server (106) based on the account token and the one or more configurations.
[0045] In an embodiment, the system (104) may transmit the account token to the one or more devices (102) and receive an authentication problem from the one or more devices (102) based on the account token. The authentication problem may be encrypted with a device token. The device token received by the system (104) may be encrypted using an Advanced Encryption Standard (AES) 128 technique based on an identifier and the account token associated the one or more devices (102).
[0046] In an embodiment, the system (104) may transmit an authentication solution to the one or more devices (102) based on the authentication problem, where the authentication solution may be encrypted with the device token.
[0047] In an embodiment, the system (104) may determine if a match exists between the authentication problem and the authentication solution. In response to a positive determination the system (104) may transmit a data transfer request to the one or more devices (102). In response to a negative determination, the system (104) may terminate the data transfer request associated with the one or more devices (102).
[0048] In an embodiment, the system (104) may receive encrypted data from the one or more devices (102) for a predetermined period based on the data transfer request and transmit the encrypted data to the cloud server (106). The encrypted data received by the system (104) may be encrypted using an AES-128 cipher block chaining message (CCM) mode, including a nonce and a device key for decryption. The nonce may be calculated by the system (104) for a predetermined interval using a device ID (identification) associated with the one or more devices (102) and the device token.
[0049] In an embodiment, the system (104) may receive a renewal token from the cloud server (106) upon the expiry of the predetermined period to establish one or more updated configurations with the cloud server (106) and receive one or more updated whitelist updates associated with the one or more devices (102).
[0050] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100).
[0051] FIG. 2 illustrates an example block diagram (200) of a proposed system (104), in accordance with an embodiment of the present disclosure.
[0052] Referring to FIG. 2, the system (104) may a processor(s) (202) that may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in a memory (204) of the system (104). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (204) may comprise any non-transitory storage device including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like.
[0053] In an embodiment, the system (104) may include an interface(s) (206). The interface(s) (206) may comprise a variety of interfaces, for example, interfaces for data input and output (I/O) devices, storage devices, and the like. The interface(s) (206) may also provide a communication pathway for one or more components of the system (104). Examples of such components include, but are not limited to, processing engine(s) (208) and a database (210), where the processing engine(s) (208) may include, but not be limited to, a data management engine (212) and other engine(s) (214). In an embodiment, the other engine(s) (214) may include, but not limited to, an input/output engine, and a notification engine.
[0054] In an embodiment, the processing engine(s) (208) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine(s) (208). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine(s) (208) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing engine(s) (208) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine(s) (208). In such examples, the system (104) may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system (104) and the processing resource. In other examples, the processing engine(s) (208) may be implemented by electronic circuitry.
[0055] In an embodiment, the processor (202) may transmit an onboarding request to a cloud server (106) via a data management engine (212). The processor (202) may receive an account token in response to the onboarding request and store the account token in the database (210). The cloud server (106) may include one or more whitelist updates associated with one or more devices (102).
[0056] The processor (202) may establish one or more configurations with the cloud server (106) based on the account token. The processor (202) may receive the one or more whitelist updates associated with one or more devices (102) from the cloud server (106) based on the account token and the one or more configurations.
[0057] In an embodiment, the processor (202) may transmit the account token to the one or more devices (102) and receive an authentication problem from the one or more devices (102) based on the account token. The authentication problem may be encrypted with a device token. The device token received by the processor (202) may be encrypted using an AES 128 technique based on an identifier and the account token associated the one or more devices (102).
[0058] In an embodiment, the processor (202) may transmit an authentication solution to the one or more devices (102) based on the authentication problem, where the authentication solution may be encrypted with the device token.
[0059] In an embodiment, the processor (202) may determine if a match exists between the authentication problem and the authentication solution. In response to a positive determination, the processor (202) may transmit a data transfer request to the one or more devices (102). In response to a negative determination, the processor (202) may terminate the data transfer request associated with the one or more devices (102).
[0060] In an embodiment, the processor (202) may receive an encrypted data from the one or more devices (102) for a predetermined period based on the data transfer request and transmit the encrypted data to the cloud server (106). The encrypted data received by the processor (202) may be encrypted using an AES-128 CCM mode, including a nonce and a device key for decryption. The nonce may be calculated by the processor (202) for a predetermined interval using a device ID associated with the one or more devices (102) and the device token.
[0061] In an embodiment, processor (202) may receive a renewal token from the cloud server (106) upon the expiry of the predetermined period to establish one or more updated configurations with the cloud server (106) and receive one or more updated whitelist updates associated with the one or more devices (102).
[0062] Although FIG. 2 shows exemplary components of the system (104), in other embodiments, the system (104) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2. Additionally, or alternatively, one or more components of the system (104) may perform functions described as being performed by one or more other components of the system (104).
[0063] FIG. 3 illustrates an example flow diagram (300) of data flow associated with the proposed system (104), in accordance with an embodiment of the present disclosure.
[0064] As illustrated in FIG. 3, in an embodiment, at step 1.0 a gateway listener (308) may check if a listener is already onboarded. At step 1.1, a gateway host (304) may receive an onboarding request form the gateway listener (308). At step 1.2, the onboarding request may be received at the cloud (306) from the gateway host (304). The cloud (306) may send an onboarding token to the gateway host (304), at step 1.3. The gateway host (304) may send an onboarding token to the gateway listener (308), at step 1.4. The gateway listener (308) may set an onboarding token at step 1.5.
[0065] In an embodiment, the gateway listener (308) may send an onboarding ACK to the gateway host (304), at step 1.6. The gateway host (304) may send an onboarding ACK to the cloud (306), at step 1.7. The gateway host (304) may publish active configuration at the cloud (306), at step 1.8. Further, the cloud (306) may send a latest configuration to the gateway host (304), at step 1.9. The gateway listener (308) may send a configuration request to the gateway host (304), at step 1.10. At step 1.11, the gateway host (304) may send latest configuration to the gateway listener (308). The gateway listener (308) may send a configuration ACK request to the gateway host (304), at step 1.12. Next, at step 1.13, the gateway host (304) may send a configuration ACK response to the gateway listener (308).
[0066] In an embodiment, the gateway listener (308) may start a scanning process at step 1.14. At step 1.15, the gateway host (304) may send information pertaining to subscription for new whitelisting device to the cloud (306). Subsequent to this, the cloud (306) may send a whitelist update to the gateway host (304), at step 1.16. The gateway host (304) may store the new update at step 1.17. Next, at step 1.18, the gateway host (304) may send an Edge Data (ED) onboarding package/delete ED/delete all EDS information to the gateway listener (308). At step 1.19, the gateway listener (308) may send an onboarding acknowledgement to the gateway host (304). The gateway listener (308) may then send a whitelist conformation to the gateway host (304), at step 1.20. The gateway host (304) may accumulate ACK and schedule to send the ACK to the cloud (306), at step 1.21. At step 1.22 and step 1.23, the gateway listener (308) may send Edge Data to the gateway host (304). At step 1.24, the gateway listener (308) may send an ED configuration request to the gateway host (304). Further, at step 1.25, the gateway listener (308) may send an ED configuration set to the gateway host (304). At step 1.26, the gateway listener (308) may send an ED configuration request to the gateway host (304). At step 1.27, the gateway listener (308) may send an ED configuration set to the gateway host (304). At step 1.28, the gateway listener (308) may send a disconnect event and ED details to the gateway host (304).
[0067] In an embodiment, at step 2.1, the IoT edge device (302) may check with the gateway listener (308), whether the ED is already onboarded, and if not, send an onboarding request to the IoT edge device (302). On receiving this, the gateway listener (308) may send an onboarding token to the IoT edge device (302). The IoT edge device (302) may further generate an Auth problem and send the Auth problem to the gateway listener (308), at step 2.4. This leads to the IoT edge device (302) receiving an Auth solution, at step 2.6. Thereafter, an ACK authentication may be received at the gateway listener (308), at step 2.7.
[0068] In an embodiment, at step 2.8, an Edge data request may be received at IoT edge device (302) from the gateway listener (308). In response, the IoT edge device (302) may send data if available else consider sent data as complete, at step 2.9. A data ACK may be received, at step 2.10, by the IoT edge device (302). Again, at step 2.11, the IoT edge device (302) may send available data else may consider data as complete. The gateway listener (308) may check if the configuration ID and current configuration ID are latest, at step 2.12 and may send a configuration sent message to the IoT edge device (302), at step 2.13.
[0069] In an embodiment, the IoT edge device (302) may send a configuration set message to the gateway listener (308), at step 2.14. Again, the gateway listener (308) may send a configuration sent message to the IoT edge device (302), at step 2.15, and the IoT edge device (302) may send the configuration set message to the gateway listener (308), at step 2.16. In response, the gateway listener (308) may send a device disconnect message to the IoT edge device (302), at step 2.17. Finally, the gateway host (302) may send data to cloud (306), at step 3.0 and at step 3.1.
[0070] Therefore, in accordance with embodiments of the present disclosure, various stages of communication in the data flow may include various steps. At a first stage, the gateway (304) may send an onboarding request to the cloud (306), and in response receive an account token. After the onboarding token is set (as mentioned in step 1.5) and acknowledgment is sent (at step 1.7), the gateway host (304) may receive latest configurations from the cloud (306) and send the latest configurations to the gateway listener (306) (steps 1.8 – steps 1.13).
[0071] In an embodiment, at a second stage, onboarding and whitelisting of the IoT edge device (302) may be performed. After the configuration is set, the gateway listener (308) may start scanning (at step 1.14). The gateway host (302) may share a list of new devices with the cloud (306) and may receive a whitelist update (at step 1.16). If a tracker/IoT edge device (304) is not onboarded already, an on-boarding request may be sent to the gateway listener (308) (at step 2.1). Further, the IoT edge device (302) may receive an onboarding token and store the onboarding token. The communication between the IoT edge device (302) and gateway listener (308) may always be initiated by the IoT edge device (302). After the IoT edge device (302) initiates communication, the IoT edge device (302) may switch to a passive mode where the IoT edge device (302) may respond to the requests received from the gateway listener (308).
[0072] In an embodiment, at a third stage, a gateway authentication may be performed. The IoT edge device (302) may generate an authentication problem and send the authentication problem to the gateway listener (308) (at step 2.4). This problem may be any mathematical computation challenge easily solvable by the IoT edge device (302). The authentication problem may be encrypted by the ED_token received by the IoT edge device (302). The gateway (304) does not have this token stored, but may calculate this token using following instruction:
ED_token = AES-128(ED_public_identifier, key=account_token)
[0073] This way, the gateway (304) may support a large number of IoT edge devices in a single account without affecting the efficiency. The gateway (304) may then then solve this problem and encrypt again with the same ED_token and send the across ED_token the IoT edge device (302). If the solution received matches the expectation, the gateway (304) may be successfully authenticated and data transfer may be initiated.
[0074] In an embodiment, at a fourth stage, a data transfer may be performed. Available data may be sent by the IoT edge device (302) after a request received from the gateway listener (308). The data sent may also be encrypted with AES-128 CCM mode that requires nonce along with the IoT edge device’s key for decryption. This nonce may not be directly shared but may be deduced using following described pseudocode at the cloud (306).
nonce cal_nonce(ED_token, deviceID, epochTime)
{
temp = ED_token + deviceID + epochTime;
hash = sha256(temp)
memcpy(nonce, hash, supported_nonce_len)
return nonce
}
[0075] FIG. 4 illustrates an example token renewal process (400) associated with the proposed system (104), in accordance with an embodiment of the present disclosure.
[0076] As illustrated in FIG. 4, in an embodiment, the token renewal process may include the following steps.
[0077] At step 408: When the account token expires, the cloud (406) may initiate a token update. Initially, the cloud (406) may generate a new token and then prepare a token update message. Further, the cloud (406) may prepare a whitelist update with the new token.
[0078] At step 410: The token update may be sent to the gateway (404).
[0079] At step 412: The token update and the whitelist with the new token may be sent to the gateway (404).
[0080] At step 414: Thereafter an ACK may be received by the cloud (406).
[0081] At step 416: The IoT edge device (402) may send an Adv message to the gateway (404).
[0082] At step 418: The gateway (404) may check the whitelist.
[0083] At step 420: Thereafter, an authentication may be done by the IoT edge device (402) using an old token received from the gateway (404).
[0084] At step 422: The IoT edge device (402) may transfer the data to the gateway (404).
[0085] At step 424: In response IoT edge device (402) may receive the token update from the gateway (404).
[0086] At step 426: The IoT edge device (402) may send an ACK message to the gateway (404).
[0087] At step 428: The gateway (404) may mark media access control address (MAC) for the token renewed.
[0088] FIG. 5 illustrates an exemplary computer system (500) in which or with which embodiments of the present disclosure may be implemented.
[0089] As shown in FIG. 5, the computer system (500) may include an external storage device (510), a bus (520), a main memory (530), a read-only memory (540), a mass storage device (550), a communication port(s) (560), and a processor (570). A person skilled in the art will appreciate that the computer system (500) may include more than one processor and communication ports. The processor (570) may include various modules associated with embodiments of the present disclosure. The communication port(s) (560) may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication ports(s) (560) may be chosen depending on a network, such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (500) connects.
[0090] In an embodiment, the main memory (530) may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory (540) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chip for storing static information e.g., start-up or basic input/output system (BIOS) instructions for the processor (570). The mass storage device (550) may be any current or future mass storage solution, which can be used to store information and/or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces).
[0091] In an embodiment, the bus (520) may communicatively couple the processor(s) (570) with the other memory, storage, and communication blocks. The bus (520) may be, e.g., a Peripheral Component Interconnect PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), USB, or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (570) to the computer system (500).
[0092] In another embodiment, operator and administrative interfaces, e.g., a display, keyboard, and cursor control device may also be coupled to the bus (520) to support direct operator interaction with the computer system (500). Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) (560). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system (500) limit the scope of the present disclosure.
[0093] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be implemented merely as illustrative of the disclosure and not as a limitation.

ADVANTAGES OF THE INVENTION
[0094] The present disclosure provides a system and a method that prevents man in the middle attack as the Internet of Things (IoT) Edge device authenticates a recipient before sending data out and offers protection against malicious attacks.
[0095] The present disclosure provides a system and a method that prevent a distributed denial of service (DDoS) attack as communication from all the IoT Edge devices are protected through an encryption channel where a cloud server easily identifies and blocks unwanted communication.
[0096] The present disclosure provides a system and a method that offers data Integrity and confidentiality as data is protected using an Advanced Encryption Standard (AES) 128 cipher block chaining message (CCM) mode encryption, maintaining integrity of the data.
[0097] The present disclosure provides a system and a method where a central device/gateway provides service to peripheral (IoT Edge devices) devices exclusively from same account.
[0098] The present disclosure provides a system and a method where the cloud controls account mapping of the devices, so that the devices may be easily and dynamically moved across accounts without need of a firmware update.
,CLAIMS:1. A system (104) for authentication and data security of devices, the system (104) comprising:
a processor (202); and
a memory (204) operatively coupled with the processor (202), wherein said memory (204) stores instructions which, when executed by the processor (202), cause the processor (202) to:
transmit an onboarding request to a cloud server (106);
receive an account token in response to the onboarding request;
establish one or more configurations with the cloud server (106) based on the account token;
receive one or more whitelist updates associated with one or more devices (102) from the cloud server (106) based on the account token and the one or more configurations;
transmit the account token to the one or more devices (102);
receive an authentication problem from the one or more devices (102) based on the account token, wherein the authentication problem is encrypted with a device token;
transmit an authentication solution to the one or more devices (102) in response to the authentication problem, wherein the authentication solution is encrypted with the device token;
determine if a match exists between the authentication problem and the authentication solution; and
in response to a positive determination:
transmit a data transfer request to the one or more devices (102);
receive encrypted data from the one or more devices (102) for a predetermined period based on the data transfer request; and
transmit the encrypted data to the cloud server (106).
2. The system (104) as claimed in claim 1, wherein in response to a negative determination, the processor (202) is to terminate the data transfer request associated with the one or more devices (102).
3. The system (104) as claimed in claim 1, wherein the device token is encrypted based on an identifier and the account token associated with the one or more devices (102) using an Advanced Encryption Standard (AES) 128 technique.
4. The system (104) as claimed in claim 1, wherein the encrypted data is encrypted using a nonce and a device key.
5. The system (104) as claimed in claim 4, wherein the processor (202) is to determine the nonce for the predetermined period using a device identifier (ID) associated with the one or more devices (102) and the device token.
6. The system (104) as claimed in claim 1, wherein the processor (202) is to receive a renewal token from the cloud server (106) upon an expiry of the predetermined period to establish one or more updated configurations with the cloud server (106), and receive one or more updated whitelist updates associated with the one or more devices (102).
7. A method for authentication and data security of devices, the method comprising:
transmitting, by a processor (202) associated with a system (104), an onboarding request to a cloud server (106);
receiving, by the processor (202) an account token in response to the onboarding request;
establishing, by the processor (202), one or more configurations with the cloud server (106) based on the account token;
receiving, by the processor (202), one or more whitelist updates associated with one or more devices (102) from the cloud server (106) based on the account token and the one or more configurations;
transmitting, by the processor (202), the account token to the one or more devices (102);
receiving, by the processor (202), an authentication problem from the one or more devices (102) based on the account token, wherein the authentication problem is encrypted with a device token;
transmitting, by the processor (202), an authentication solution to the one or more devices (102) based on the authentication problem, wherein the authentication solution is encrypted with the device token;
determining, by the processor (202), if a match exists between the authentication problem and the authentication solution; and
in response to a positive determination:
transmitting by the processor (202), a data transfer request to the one or more devices (102);
receiving, by the processor (202), encrypted data from the one or more devices (102) for a predetermined period based on the data transfer request; and
transmitting, by the processor (202), the encrypted data to the cloud server (106).
8. The method as claimed in claim 7, comprising in response to a negative determination, terminating, by the processor (202), the data transfer request to the one or more devices (102).
9. The method as claimed in claim 7, comprising encrypting, by the processor (202), the received device token using an Advanced Encryption Standard (AES) 128 technique based on an identifier and the account token associated with the one or more devices (102).
10. The method as claimed in claim 7, wherein the encrypted data is encrypted using a nonce and a device key.
11. The method as claimed in claim 10, comprising calculating, by the processor (202), the nonce for the predetermined period using a device identifier (ID) associated with the one or more devices (102) and the device token.
12. The method as claimed in claim 7, comprising receiving, by the processor (202), a renewal token from the cloud server (106) upon an expiry of the predetermined period for establishing one or more updated configurations with the cloud server (106) and receiving one or more updated whitelist updates associated with the one or more devices (102).