Efficient internet-of-things (IoT) data encryption/decryption

Abstract

Techniques are disclosed for encrypting internet-of-things (IoT) data of an IoT network only once at its inception until its final consumption without intervening encryption/decryption stages/cycles. The present encrypt-decrypt-once design thus eliminates potential exposure of the IoT data in its plaintext form of a traditional approach employing intervening encryption/decryption cycles. The present design is also efficient and reduces the burden on IoT resources by eliminating the need for encrypting and decrypting the data multiple times. To accomplish these objectives, a number of schemes for device enrollment, authentication, key distribution, key derivation, encryption and encoding are disclosed. The devices employ authenticated encryption because it provides confidentiality, integrity, and authenticity assurances on the encrypted data. The final consumption of the IoT data may be at a designated gateway or a corporate system.

Claims

1. A secure internet-of-things (IoT) network, comprising: (a) one or more edge devices and at least one gateway device on said secure IoT network, said one or more edge devices and said at least one gateway device each comprising at least one memory device storing computer-readable instructions and at least one microprocessor coupled to said at least one memory device for executing said computer-readable instructions; (b) IoT data generated by said one or more edge devices for transmission on said secure IoT network to said at least one gateway device; (c) a module on said secure IoT network for provisioning said one or more edge devices; and (d) a key server for distributing an exchanged data key (EDK) to each of said one or more edge devices; wherein each of said one or more edge devices derives a data encryption key (DEK) from said EDK and then encrypts said IoT data by an authenticated encryption employing said DEK to obtain encrypted IoT data for said transmission, and wherein said at least one gateway device decrypts said encrypted IoT data by an authenticated decryption employing said DEK derived from said EDK, and wherein a wrapped EDK is included in said transmission, said wrapped EDK obtained by said one or more edge devices by encrypting said EDK with a public key of said at least one gateway device, said public key obtained from a public key certificate broadcasted by said at least one gateway device to said one or more edge devices.

2. The secure IoT network of claim 1, wherein a certificate authority is used to issue a public key certificate to said one or more edge devices for enrollment on said secure IoT network.

3. The secure IoT network of claim 2, wherein said public key certificate undergoes authentication checks for authenticating said one or more edge devices on said secure IoT network.

4. The secure IoT network of claim 1, wherein said module in element (c) is a provisioning server that authenticates and then provisions said one or more edge devices on said secure IoT network.

5. The secure IoT network of claim 4, wherein one of a public-private keypair and a digital certificate is included in said one or more edge devices at a time of their manufacturing.

6. The secure IoT network of claim 1, wherein said key server is also utilized for authenticating said one or more edge devices.

7. The secure IoT network of claim 6, wherein a salted challenge response authentication mechanism (SCRAM) protocol is used for authenticating said one or more edges device with said key server.

8. The secure IoT network of claim 1, wherein an authentication mechanism of an underlying protocol on said secure IoT network is used for authenticating said one or more edge devices.

9. The secure IoT network of claim 1, wherein said one or more edge devices and said at least one gateway device derive said DEK from said EDK by employing a key derivation function based on a hash-based message authentication code (HKDF).

10. The secure IoT network of claim 1, wherein said authenticated encryption employs an advanced encryption standard (AES) in Galois/counter mode (GCM).

11. The secure IoT network of claim 10, wherein additional authentication data (AAD) is provided to said authenticated encryption, said AAD comprising a secure hash algorithm-256 (Sha-256) hash over fields including a protocol version (PVer), a sender ID (SID), a key ID (KID), a salt, a counter (Ctr) and a header (Hdr) of an encrypted IoT message of said encrypted IoT data for said transmission.

12. The secure IoT network of claim 1, wherein a type length value (TLV) encoding is employed to encode each field of an encrypted IoT message of said encrypted IoT data for said transmission.

13. A computer-implemented method of securing internet-of-things (IoT) data on an IoT network, said method comprising the steps of: (a) provisioning at least one edge device on said IoT network; (b) generating said IoT data by said at least one edge device; (c) distributing an exchanged data key (EDK) from a key server on said IoT network to said at least one edge device and deriving a data encryption key (DEK) at said at least one edge device; (d) encrypting at said at least one edge device said IoT data with said DEK to obtain encrypted IoT data, said encrypting utilizing an authenticated encryption; (e) transmitting said encrypted IoT data from said at least one edge device to a gateway device; (f) decrypting with said DEK said encrypted IoT data at said gateway device; and (g) sending a wrapped EDK along with said encrypted IoT data from said at least one edge device to said gateway device, said wrapped EDK obtained by said at least one edge device by encrypting said EDK with one of a public key of said gateway device and a shared secret of a DiffieHellman key-exchange between said gateway device and said at least one edge device.

14. The computer-implemented method of claim 13 utilizing a provisioning server for authenticating and then configuring said at least one edge device in said step (a).

15. The computer-implemented method of claim 14 utilizing a certificate authority for issuing a public key certificate to said at least one edge device for said authenticating.

16. The computer-implemented method of claim 14 including in said at least one edge device at a time of its manufacturing, one of a public-private keypair and a digital certificate, for said authenticating.

17. The computer-implemented method of claim 13 utilizing a salted challenge response authentication mechanism (SCRAM) protocol for authenticating said at least one edge device with said key server.

18. The computer-implemented method of claim 13 utilizing an authentication mechanism of an underlying protocol on said IoT network for authenticating said at least one edge device.

19. The computer-implemented of claim 13 employing a type length value (TLV) encoding for encoding each field of an encrypted IoT message of said encrypted IoT data for said transmitting.

Description

BRIEF DESCRIPTION OF THE DRAWING FIGURES

(1) FIG. 1 illustrates in a block diagram form the various components of a secure IoT network according to the present technology.

(2) FIG. 2 shows additional modules/servers on the IoT network of FIG. 1 to delineate various embodiments of the present design.

(3) FIG. 3 shows the various elements and steps behind the enrollment and authentication of devices at an IoT network according to the instant principles.

(4) FIG. 4 shows a conceptual diagram of an embodiment employing a salted challenge response authentication mechanism (SCRAM) mechanism/protocol for authentication of the devices with a key server.

(5) FIG. 5 shows a conceptual diagram of a key distribution scheme employing a public key certificate broadcasted by the gateway.

(6) FIG. 6 shows a conceptual diagram of a key distribution scheme employing a DiffieHellman (DH) key-exchange method employed between the gateway and the devices.

(7) FIG. 7 shows an embodiment where instead of exchanged data keys (EDKs) issued by a key server, wrapping keys are used by the gateway and the devices to derive the per-message data encryption keys (DEKs).

(8) FIG. 8 illustrates the advanced encryption standard (AES) in galois/counter mode (GCM) mode of authenticated encryption as implemented by the devices of the present design.

(9) FIG. 9 illustrates the advanced encryption standard (AES) in galois/counter mode (GCM) mode of authenticated decryption as implemented by the devices of the present design.

DETAILED DESCRIPTION

(10) The figures and the following description relate to preferred embodiments of the present invention by way of illustration only. It should be noted that from the following discussion, alternative embodiments of the structures and methods disclosed herein will be readily recognized as viable alternatives that may be employed without departing from the principles of the claimed invention.

(11) Reference will now be made in detail to several embodiments of the present invention(s), examples of which are illustrated in the accompanying figures. It is noted that wherever practicable, similar or like reference numbers may be used in the figures and may indicate similar or like functionality. The figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.

(12) The present invention will be best understood by first reviewing systems and methods for securing data-at-rest in a secure IoT environment as illustrated in FIG. 1. Embodiment 100 of FIG. 1 shows an internet of things or internet-of-things (IoT) site or environment 102 that contains a variety of IoT devices or endpoints or edge devices 108. Any number of IoT edge devices 108A, 108B, . . . are permitted at site 102. Their number may be in the dozens, hundreds, thousands or even more depending on the implementation. There are also a number of IoT gateway devices 104. Any number of such IoT gateway devices, or simply gateway devices, or even more simply gateways are possible. Two such gateways 104A and 104B are explicitly shown in FIG. 1.

(13) IoT environment or site 102 can be practically any environment or location or site, stationary or moving, terrestrial or extra-terrestrial, where IoT devices 108 are deployed. Exemplarily, site 102 can be an oilrig where IoT devices/sensors 108 are used to monitor the various operational parameters of the rig. For example, devices/sensors 108 may be measuring tank liquid levels, loads on winches, pressures on the drill-bit, torque on the top drive, etc. IoT site/environment may alternatively be an embassy and devices/sensors 108 may be various security devices, such as surveillance cameras, fence monitors, intrusion detectors, etc. Site 102 may alternatively be virtually any other site and sensors 108 may be deployed to monitor various aspects of the systems deployed there.

(14) Environment 102 may also be a medical facility, such as a hospital, and devices/sensors 108 may be various types of medical and infrastructure sensors, such as pressure, temperature and flow sensors installed on anesthesia delivery machines, respiratory monitoring and blood pressure monitoring equipment, ventilators oxygen concentrators, sleep apnea machines, blood analyzers ventilators, kidney dialysis machines, infusion and insulin pumps, organ transplant system temperature monitoring and control, neonatal intensive care units, blood analyzers, hospital beds, surgical fluid management systems, and pressure-operated dental instruments, gas mixing, and electro-surgery. Devices/endpoints/sensors 108 may also be image sensors deployed equipment related to radiography, minimally invasive surgery, fluoroscopy, cardiology, mammography, dental imaging, endoscopy, external observation, laboratory equipment, ocular surgery and observation, and artificial retinas, etc. Sensors 108 may also be accelerometers and biosensors deployed according to their medical applications.

(15) IoT site 102 may also be any other site of scientific exploration such as polar and ocean exploration expeditions and space missions. Site 102 may also be a moving vehicle, such as a truck driving to a site to drop off or pick up goods, or a train, a car, a bus, a plane, a rocket, etc. Above is only a handful of examples of IoT site/environment 102 of the embodiment shown in FIG. 1, and the present technology admits to almost endless possibilities for site 102 and sensors 108 for its various implementations. As noted, the IoT sites, such as site/environment 102 may contain hundreds, or thousands or more IoT sensors devices 108.

(16) FIG. 1 also shows a communication network 112 connecting site 102 to a backend corporate data center 116. Communication network 112 is a Wide Area Network (WAN) like the internet or the “cloud” or a Metropolitan Area Network (MAN) with physical connections supported by any combinations and variety of communications infrastructure including wired, optical and wireless. Corporate data center 116 contains various kinds of computing resources or servers required by the corporation.

(17) Gateways 104 are responsible for sending commands to edge devices 108 as well as collecting, aggregating, collating, tallying or in any way, shape or form processing IoT data 114 generated by these devices at site 102. Either in response to the commands sent by the gateways, or automatically without any such explicit commands, the edge devices perform their intended functions that result in the generation of IoT data 114. They then transmit this IoT data to gateways 104 for aggregation/processing. Ultimately, gateways 104 may further report the aggregated/processed IoT data 114 to corporate data center 116. More specifically, they typically report the data to an appropriate target backend server(s) (not shown in FIG. 1) at data center 116.

(18) IoT data 114 is collected via a local area network 110 at site 102 of which all IoT devices 108 and gateways 104 are members. Local area network 110 may be implemented using one of a number of techniques available in the art. As shown by the lock symbols in FIG. 1, IoT data 114 is usually transmitted/communicated within site 102 and to/from corporate data center 116 in a secure manner, taking advantage of one of a number of available technologies of the art for securing data in-transit. Such techniques include secure socket layer (SSL)/transport layer security (TLS), IPSec, etc. Similarly, and as shown by the lock symbols, data-at-rest residing in the storage space/media of gateway devices 104A, 104B may also be secured as taught in commonly owned U.S. patent application Ser. No. 16/359,964 filed on 20 Mar. 2019.

(19) One of the advantages of the present encrypt-decrypt-once design is that it obviates the need for SSL/TLS. This is because it provides end-to-end encryption for the entire lifecycle of IoT data without superfluous and expensive intermediate encryption/decryption cycles. However, if SSL/TLS security already exists at an IoT infrastructure, the present solutions can easily co-exist with such technologies. Explained further, in such an environment, data encrypted by IoT devices according to present embodiments, will be re-encrypted/decrypted by SSL/TLS for communication between various nodes on network 110.

(20) However, during the various stages of its lifecycle in an IoT architecture, such as in between its transmission and local storage, IoT data 114 may be decrypted, re-encrypted, and decrypted a number of times. After decryption, and before re-encryption, IoT data 114 is in plaintext form and open to an attack. More specifically, IoT data 114 of FIG. 1 may be encrypted during its transmission from an edge IoT device such as device 108B to gateway 104A. However, once it arrives at gateway 104A, it would be decrypted and re-encrypted for processing and/or storage on gateway 104A. Similarly, the data may be re-encrypted before its transmission over network 112 to corporate data center 116, where it may be decrypted and re-encrypted again. Alternatively, the data may be processed at gateway 104A and then sent to corporate data center 116. During each of such decryption and encryption cycles/stages, IoT data 114 is exposed as a target for a data hack/theft/attempt/attack.

(21) What is needed is a way to encrypt IoT data 114 once at its inception on an edge device or at an endpoint, such as device 104B and then keep it encrypted until decryption for its final consumption. The final consumption may be at gateway 104A or corporate data center 116 or any other recipient system/device or point of interest. This is one of the key benefits provided by the instant design. The instant technology not only protects the data by preventing its exposure during various decryption/encryption stages but is also efficient as a result of reducing the computation burden on the architecture by encrypting the data only once and keeping it encrypted until its final consumption.

(22) Let us now look in greater detail at how the instant design accomplishes its “encrypt-decrypt-once” objectives. As shown in the block diagram of a preferred embodiment 200 of FIG. 2, there is a provisioning/authentication module or server 202 and a key manager module or server 204. Provisioning/authentication module/server 202 is responsible for authentication and provisioning of devices on network 110. Let us now look at the functionality of this module/server in greater detail.

Provisioning/Authentication

(23) IoT device provisioning consists of the following key functions performed by module 202.

(24) Provisioning Tasks:

(25) 1. Authenticating each device and establishing its initial connection on network 110. 2. Applying proper configuration to the device based on the specific requirements of IoT site 102.

(26) As noted, the above tasks are performed by provisioning server 202. Per task (1) above, a new device must be authenticated on network 110 before its connection to the network can be established. As such, sometimes provisioning server 202 may also be referred to as a provisioning and authentication or provisioning/authentication server 202. In alternative embodiments, task (1) above may be performed by a dedicated authentication server while only task (2) is performed by the provisioning server. Referring still to FIG. 2, key manager module/server or simply key server 204 is responsible for allocating and distributing keys to the participating devices on network 110.

(27) FIG. 2 shows various edge devices 108B-E of FIG. 1 on network 110 on which IoT data 114 is being transmitted. Not all the devices and their reference numerals from FIG. 1 are shown in FIG. 3 for reasons of clarity. Now, starting from the beginning, let us see what happens when we add a new device to network 110.

(28) New devices are added to IoT network 110 via a provisioning process carried out by provisioning server 202. Provisioning of new devices consists of tasks (1) and (2) as noted above. Task (1) which consists of the process of authentication ensures that the new IoT devices on network 110 are legitimate participants of the network. More specifically, the authentication process consists of ascertaining that a device is what it says it is. Those devices whose credentials are verified on network 110 are authenticated and all other devices are rejected or denied. Ultimately, authentication is needed to have a consistent and unforgeable way to identify the edge devices.

(29) Task (2) consists of properly configuring the new devices on network 110 according to the requirements of IoT site 102. One such requirement may be that each new device sends its IoT data 114 to one or more designated gateways. For instance, if the new device being added is edge device 108E, then the requirements of IoT site 102 may dictate that device 108E be configured to send its IoT data to gateway 104A shown in FIG. 2.

(30) Let us now look at task (1) and (2) of provisioning performed by our provisioning/authentication server 202 shown in FIG. 2 in even greater detail. In the preferred embodiment, a certificate authority (CA) 208 shown in FIG. 2 is used to generate credentials for the IoT devices per below explanation. This process of obtaining credentials/certificates by the devices is also referred to as enrollment according to the present design. After the credentials have been obtained by our new device 108E, or in other words, after the new device has been enrolled, it can then authenticate itself with provisioning server 202 as provisioning task (1) above.

(31) Provisioning server 202 can then provision the device as per task (2) above, after which it can start communicating with its dedicated gateway 104A. The present design thus allows for auto-provisioning or “provision on connect” for new devices at IoT site 102 because no manual intervention is required for authentication/provisioning of new device.

(32) In the preferred embodiment, each new edge device is pre-configured to include a public-private keypair associated with public key infrastructure (PKI) technology, and the fully qualified domain name (FQDN) of CA 208 on network 110 at the time of its manufacturing. When a new device, such as device 108E first boots up on network 110, it sends a certificate/code signing request (CSR) to CA 208. More specifically, it first uses a Domain Name System (DNS) to obtain the IP address of the CA on network 110 based on the FQDN of CA 208 and then sends it the CSR.

(33) Further explained, CA 208 has a public key that is pre-known to all the devices on network 110. This knowledge in the devices on network 110 may be provided by an introduction process to be further explained below, or may be embedded in the devices and more specifically in their trusted stores at the time of their manufacturing. In any case, CA 208 also has its corresponding private key that no other device knows. When creating the CSR, our new edge device 108E includes its public key in it along with its identity information. Using its private key, it then signs the CSR, more specifically its identity information in the CSR. In one embodiment, its identity information in the CSR is its Media Access Control (MAC) address. In alternative embodiments, its identity information is its FQDN on network 110.

(34) Upon receiving the CSR, CA 208 first ensures the authenticity of the CSR by verifying its signature using the public key of the device received in the CSR. Once the CSR is verified, CA 208 then validates edge device 108E to ensure that it is what it says it is. In other words, it validates the identity information of the device obtained in the CSR. For this purpose, it ensures that the MAC address or FQDN of the device in the CSR is indeed the MAC/FQDN of device 108E. If the identity information is a MAC address, as in one embodiment, then CA 208 consults a database containing valid MAC addresses of edge devices that are allowed to participate on network 110.

(35) If the identity information of edge device 108E is an FQDN, as in another embodiment, then CA 208 consults DNS 210 shown in FIG. 2. DNS 210 keeps a table of IP addresses and the FQDNs of devices on network 110 that are allowed to participate at IoT site 102. Specifically, it stores each FQDN or a host name on network 110 and the corresponding IP address that the name “points to” in an address record or an A record. It holds such A records for as many or a range of IP addresses that are allowed for edge devices 108 on network 110. Therefore, when CA 208 validates the IP address of edge device 108E in the above example, it looks up the IP address in DNS 210. DNS 210 can verify that the IP address is indeed an allowable IP address on network 110. Moreover, it can also verify that the IP address is not already used by another edge device. For this purpose, CA 208 may issue a command such as “nslookup” on DNS 210.

(36) Once the validation of our new edge device 108E has been performed by CA 208, it can then issue the proper credentials to the device. For this purpose, in one embodiment, it would take the public key of edge device 108E that it received in the CSR along with the validation information of the device, such as its MAC or IP address, collectively in a credentials document known as the public key certificate of the device. It also includes the IP address of provisioning server 202 on network 110 in the certificate. CA 208 then digitally signs the public key certificate with its private key to obtain a digitally signed certificate for our newly enrolled edge device 108E. CA 208 then sends this certificate to edge device 108E which can now verify the authenticity of the certificate by decrypting it with the public key of CA 208. As noted, this process of obtaining credentials or digital certificates by the devices from CA 208 is also referred to herein as enrollment.

(37) In related embodiments, the public key certificate or digital certificate for device 108E explained above follows the X.509 standard. In still related variations, such a certificate may also be included in the device at the time of its manufacturing. Regardless, once edge device 108E has its certificate/credentials, it can now contact provisioning server 202 with an authentication request and whose IP address it obtained in the certificate. The authentication request contains its digital certificate obtained above. Once provisioning/authentication server 202 receives the certificate and the authentication request, it performs a number of checks on the certificate to ensure that it is valid. For this purpose, it also contacts CA 208. These checks consist of at least the following.

(38) Authentication Checks:

(39) 1. Has the digital certificate been issued/signed by a trusted CA, for example, CA 208 on network 110? To answer this question, it verifies the signature of the certificate with the public key of the CA that is stored in its trusted certificates store or simply trusted store. 2. Is the certificate expired? For this purpose, it checks both the start and end dates specified in the certificate. 3. Has the certificate been revoked? For this purpose, it contacts CA 208 to see if the certificate is in a certificate revocation list (CRL). More preferably, it contacts an online certificate status protocol (OCSP) service for this purpose. 4. Has the client provided proof of possession (PoP)? To answer this question, edge device 108E would have encrypted some test data with its private key and included both the plaintext and encrypted test data in the certificate sent to provisioning/authentication server 202. Upon receipt, server 202 decrypts the encrypted data with the public key of the device in the certificate. If the result matches the plaintext data sent by the device, then this is proof that the device is in possession of its private key.

(40) If all the above authentication checks performed by provisioning/authentication server 202 in provisioning task (1) noted above succeed, then the authentication request of our new edge device 108E is accepted. As a result, provisioning server 202 performs provisioning task (2) noted above. For this purpose, it sends the IP address of designated gateway 104A (or other gateways/recipient as needed) with which the device should communicate for commands and IoT data.

(41) The above configuration information to device 108E may be sent in a format suitable for the device. From here onwards, subject to encryption of its IoT data per below teachings, the device can start communicating with its dedicated gateway 104A directly. Furthermore, any other configuration information that may be required by the device at site 102 can also be sent by server 202 as a part of provisioning task (2) as needed.

(42) On the other hand, if any of the above authentication tasks fails, the device is denied authentication by authentication server 202 per provisioning task (1) above. As such, it is also not provided any configuration information by server 202 to operate on network 110 per provisioning task (2) above. For instance, it is not provided with the IP address of the gateway to communicate with. It may even be blocked or sent a shutdown command by provisioning server 202.

(43) Note also that the above-explained authentication would not be successful, if CA 208 could not verify the signature of edge device 108E in its CSR message, or if the CA could not validate the credentials of the edge device or if the edge device could not verify the signature of the CA in its certificate. In one such exemplary case, if there were a fake/malicious device being added to site 102 and specifically to network 110, it would not have the correct private key to sign the CSR that is verified by the CA. In another such exemplary case, if a fake/malicious CA were to issue the public key certificate to the device, it would not possess the correct private key of real CA 208 to sign the certificate. As such, it would not be verifiable by the edge device using the public key of the legitimate CA pre-known to all devices on network 110 per above.

(44) The above processes of enrollment, provisioning and authentication scheme of new devices in the present embodiment is also shown in FIG. 3 in a flow diagram form in conjunction with FIG. 2. Specifically, flow chart 300 of FIG. 3 shows the various steps behind provisioning/authentication tasks (1) and (2) per above explanation. We begin by process/block/box/step 302 representing that a new device, such as edge device 108E first boots up on network 110. Device 108E then creates and sends a certificate signing request (CSR) to CA 208 per above explanation as shown by box 304. CA 208 then verifies the authenticity of the CSR and validates the identity of the device received in the CSR as shown by box 306.

(45) Based on the results of the above, a decision is made by CA 208 whether to proceed forward with enrollment of the new device or not. Specifically, and as shown by decision diamond 308, if the CSR is verified and subsequently the identity of the device is validated, execution proceeds to block 310. This is shown by the arrow labeled Yes out of decision diamond 308. If however, any of the above checks fail, the enrollment is denied to the new device 108E, as shown by process box 322 and arrow labeled No emerging out of diamond 308.

(46) Block 310 represents that upon successful enrollment, CA 208 prepares and sends the public key certificate or simply digital certificate to device 108E. The device then creates an authentication request containing its digital certificate for provisioning/authentication server 202 as shown by block 312. At this point, provisioning/authentication server 202 verifies the digital certificate by performing authentication checks (1) through (4) provided above. This is shown by block 314.

(47) As shown by decision diamond 316, if the authentication checks are successful, then authentication is accepted as shown by arrow labeled Yes out of decision diamond 316. If however, any of the authentication checks fail, then authentication is denied as shown by block 324 and arrow labeled No out of diamond 316. If the authentication is successful, then provisioning/authentication server performs provisioning task (2) noted above and as shown by box 318 in flowchart 300. Per above explanation, provisioning server now configures device 108E by sending it any necessary information as per the requirements of IoT site 102 of FIG. 1-2. This may include IP address of the designated gateway 104A for the device. By utilizing encryption of its IoT data per below teachings, device 108E is now ready to securely communicate with the gateway as shown by block 320.

(48) In addition to edge devices 108, when any other module/device, such as key server 204 is initially connected to network 102, it is also authenticated. This authentication is also performed in conjunction with CA 208 and provisioning/authentication server/module 202 per above explanation. Of course, the exceptions to the above are CA 208 and provisioning/authentication module 202 themselves. These privileged modules/servers need to be installed on network 110 using a physically secure and typically a manual/non-automated process involving authorized personnel.

(49) In related embodiments, the digital certificate obtained by devices 108 above, may also have an expiration date/time after which it expires, subsequent to which the respective device needs to re-enroll with CA 208 and have a new digital certificate issued. Such a variation provides added security to the system by periodically re-issuing fresh certificates to devices that may be present on network 110 for a long time or whose certificates may have gone “stale”. The process of re-enrollment with CA 208 and re-authentication of the devices with provisioning/authentication server 202, reconfirms the legitimacy of the devices on network 110. Such a process is analogous to the familiar process of password expiration known to skilled readers.

(50) In still other embodiments, the present technology innovates over existing provisioning techniques such as Microsoft Azure IoT Hub Device Provisioning Service and Amazon AWS IoT Device Provisioning. For details on these services, the reader is referred to the relevant web pages of these services provided by respective vendors. Like the prior embodiments, in the present embodiments also, each device is pre-configured to include a public-private keypair as well as the FQDN of CA 208.

(51) However, the new devices authenticate to key manager/server 204 in addition to or instead of provisioning/authentication server 202. In other words, when a new device, for example, device 108D of FIG. 2, first boots up on network 110, it first obtains its public key certificate from CA 208 as in the prior embodiments. Recall that in the prior embodiments, at this point the device authenticates itself to/with provisioning/authentication server 202. However, in the present embodiment, instead of or in addition to authenticating with provisioning server 202, it creates and sends an authentication request to key server/manager 204 of FIG. 2 introduced earlier.

(52) The process of authenticating with key server 204 is similar to that with provisioning/authentication server 202 explained earlier. In other words, new device 108D sends its public key certificate or digital certificate to key server 204 which verifies it with CA 208 by performing at least authentication checks (1) through (4) presented above. If key server 204 is able to authenticate device 108D then it can now issue an exchanged data key (EDK) from which the device can derive its data key or data encryption key (DEK) for encrypting its IoT data. The encrypted IoT data may be destined for designated gateway 104A or for local storage on device 108D as per the encrypt-decrypt-once design of the present technology. Key distribution and management as well as key derivation, encryption and data encoding will be explained in detail further below.

(53) In still other embodiments, an edge device is authenticated to/with to provisioning server 202 as in the prior embodiments. However, after the device is authenticated, provisioning server 202 issues a per-device key to the authenticated edge device. The edge device can now use this key to authenticate to key server 204 of FIG. 2. It does so by using a salted challenge response authentication mechanism (SCRAM) mechanism/protocol. Those skilled in the art will appreciate that a SCRAM protocol is useful for exchanging keys over a non-secure channel by providing a proof of knowledge or secret between two parties without revealing that secret. Thus, edge device 108D provides its key obtained from provisioning server 202 above in a SCRAM protocol to key server 204 to prove its authenticity.

(54) Let us now see how the SCRAM mechanism is specifically applied to our IoT site 102 of FIG. 2 and the above example in the present embodiment. Device 108D uses its key obtained from provisioning server 202 to compute a hash message authentication code (HMAC) to arrive at its client-key. It uses its client-key to create a client-proof that it sends to key server 204 along with the authentication message/request. Key server 204 authenticates the device by first computing the client-signature from the authentication message and then exclusive-ORing it with the client-proof to recover the client-key.

(55) Key server 204 then verifies the correctness of the client-key by computing the hash of the client-key and comparing the result to the stored-key stored for the device in the key server or its accompanying database. If the client-key is correct, then this proves to the key server that the device is the legitimate owner if its original key (obtained from provisioning server 202). It can now issue an EDK to the device per the key distribution and management schemes presented herein.

(56) In a converse fashion, the device can also verify the authenticity of the key server by computing the server-signature and comparing it to the value received from the key server. If the two are equal, then this proves to the device that the key server had access to the stored-key for the device. For further details of SCRAM mechanism/protocol, the inquisitive reader is referred to RFC 5802 from Internet Engineering Task Force (IETF), ISSN 2070-1721.

(57) FIG. 4 shows the conceptual diagram of present embodiment 350 in a pictorial form. Specifically, new edge device 108D authenticates itself using a public key (PK) certificate with provisioning/authentication server 202 as shown by bubble 352. If the device is authenticated, server 202 sends device 108D a per-device key per above as shown by bubble 354. Device 108D then uses this key in a SCRAM protocol to verify its authenticity with key server 204. This is shown by bubble 356. After such authentication, and as shown by bubble 358, key server 204 can now issue an EDK to device 108D.

(58) From its EDK, the device can derive its DEK for encrypting its IoT data 114 for local storage or transmission to gateway 104A as shown. Like the prior embodiments, the present embodiment also benefits from the encrypt-decrypt-once design of the present technology to encrypt IoT data 114 only once with its DEK while storing it locally or transmitting it to the gateway. The present design thus ensures the security of IoT data throughout the various stages of its lifecycle at IoT site 102 of FIG. 1-2. Note that other elements and reference numerals from drawing figures of prior embodiments and teachings are not shown in FIG. 4 to avoid clutter.

(59) In a variation of the above design, the EDK issued by key server 204 to the edge device is an HMAC itself. More specifically, the key issued is an HMAC computed by key server 204 using an HMAC generating secret key, which may be an identification information of the device such as its device ID. Alternatively, a salting scheme may be employed to ensure uniqueness of the HMAC generating secret key per device or related family of devices. The HMAC may be computed using a secure hashing algorithm such as Secure Hash Algorithm-256 or Sha-256 for short.

(60) The device ID in the present embodiment may be the MAC address of the device or its device number or the like. The advantage of the present scheme is that the HMAC keys for the devices need not be stored in a database by key server 204 and to be provided to the gateways or corporate system(s)/server(s) for decryption of IoT data when needed. This is because they can always be regenerated on demand as long as the HMAC generating secret key are known by the gateways or corporate server(s) for the devices.

(61) The above handshake/communication of messages in-transit in the present embodiments obviates the need for other secure data-in-transit communication mechanisms on network 110. However, the present technology can easily co-exist with such mechanisms at various IoT sites. Examples of such existing techniques include SSL/TLS as noted above. This means that data encrypted by IoT devices with their DEKs per above explanation, will be re-encrypted/decrypted by SSL/TLS for communication between various nodes on network 110.

(62) In still other embodiments, authentication module 202 may authenticate a new device joining network 110 by utilizing the authentication capabilities of underlying communication protocol operating on network 110. For example, if network 110 is a wired LAN, then authentication module 202 may utilize IEEE 802.1 authentication standard already being used on network 110.

(63) Similarly, if network 110 includes a wireless network (Wifi) based on the IEEE 802.11 standard, then module 202 may utilize extensible authentication protocol (EAP) used by Wifi networks. The Wifi network may be over a transport control protocol (TCP) or a user datagram protocol (UDP) layer.

(64) Alternatively, if network 110 is a ZigBee network, then authentication module 202 may utilize the authentication framework/protocol/standard used by ZigBee networks and so. Other potential candidates for the underlying network include message queuing telemetry transport (MQTT), etc. The details of these and other prevailing authentication schemes of potential underlying communication protocols for network 110 are well understood in the art and not delved into detail in this specification.

(65) In still other variations of the above embodiments, the IoT devices do not come pre-installed with a key. Instead, a shared secret is first created between the IoT devices 108 and authentication server/module 202 of FIG. 2 and/or key server 204 in an “introduction” process. The target server/system, whether authentication server/module 202 or key server 204, with which the shared secret is created for the devices, is referred to in such a process as the “access point”. The shared secret may take the form a passphrase that may be securely entered or created between the device and the access point utilizing available techniques.

(66) For instance, the passphrase may be a personal identification number (PIN) or a passphrase entered/created on the access point when the device is physically connected to the access point (by a cable) during the introduction. Alternatively, it may be entered/created during introduction at the access point when the device is in the range of short-range short-lived radio network around the access point (such as in a Wifi protected setup (WPS) using a physical/virtual push button). As alluded to earlier, such an introduction process may also be used for allowing the devices on network 110 to acquire the knowledge of the public key of CA 208. In other words, once securely connected to the access point during introduction, the public key of the CA may be entered/transmitted to the devices.

(67) Once the shared secret between the device(s) and the access point on IoT network 110 has been created during introduction, the introduced devices can be authenticated on the network using a SCRAM protocol/mechanism. More specifically, and referring now to FIG. 2 again, new devices can authenticate themselves to provisioning/authentication server 202 and/or key server 204 by proving the possession of the shared secret without revealing the secret per above explanation. As in the other embodiments, after authentication, the devices can proceed to obtaining EDKs from key server/manager 204 per the key management/distribution schemes provided herein. As already noted, from their EDKs the device can derive their respective DEKs for encrypting-once their IoT data on network 110.

Key Management and Distribution

(68) Let us now look in detail at how the management and distribution of EDKs to IoT devices 108 over network 110 at IoT site 102 of FIG. 1-2 takes place according to the present design. The devices derive their symmetric DEKs from their EDKs with which they encrypt their IoT data. In order for an authenticated device, such as device 108E on network 110 of FIG. 2, to send encrypted IoT data 114 to its designated gateway 104A for consumption, it is essential that the gateway has a mechanism for recovering the same/original symmetric DEK required to decrypt the IoT data that was encrypted by device 108E. The same is true for any other target recipient system/device that consumes IoT data 114. The common knowledge of the symmetric encryption key between the gateway/recipient and the device can be accomplished using a number of techniques provided by the present design. These are presented below.

(69) Gateway PK Certificate-Based Key Distribution

(70) In one embodiment, gateway 104A of FIG. 2 obtains a public key certificate from CA 208 by following the above-explained process in reference to device enrollment. In summary, it sends its public key in a CSR to CA 208 which after its validation returns it its PK certificate. It then broadcasts this PK certificate on network 110 to all the devices. Each edge device, such as device 108E, receives the digital certificate, verifies the signature of the gateway and extracts the public key of the gateway from the certificate per above teachings. It then encrypts its EDK that was issued by key server 204 above to obtain its wrapped or encrypted EDK.

(71) It then periodically sends its wrapped or encrypted EDK before or after IoT data messages or simply IoT messages containing encrypted IoT data 114 that it sends to gateway 104A. This way gateway 104A receives the wrapped EDK of the device on a periodic basis. When it needs to decrypt the data from device 108E, it decrypts the wrapped EDK of device 108E by its private key to recover the same EDK issued by the key server to the device. It then derives the same DEK as the device using a salt value and a key derivation scheme as will be explained further below under key derivation, encryption and data encoding. Because the symmetric DEK thus obtained is the same DEK as was used by the device to encrypt its IoT data 114, gateway 104A can now use the DEK to decrypt encrypted IoT data from device 108E as needed.

(72) The key distribution scheme of such an embodiment is shown in FIG. 5. The drawing figure of embodiment 370 shows that gateway 104A first obtains it public key certificate or digital certificate from CA 208 per above explanation as shown by bubble 372. The gateway then broadcasts its digital certificate to all the devices as shown by bubble 374. The devices then encrypt/wrap their EDKs obtained from key server 204 (not shown in FIG. 5) and periodically send their wrapped EDK to the gateway as indicated by bubble 376. Then as shown by bubble 378, gateway 104A is then able to recover the EDKs using its private key, derive the DEKs, and then decrypt the IoT data per above explanation.

(73) In alternate variations, the device sends just the key ID of its EDK to the gateway in a metadata of each transmitted and encrypted IoT message. The gateway then calls key server 204 with the key ID to obtain the same EDK and then derives the DEK per above explanation. Key derivation, encryption and data encoding will be discussed in detail further below.

(74) DiffieHellman (DH) Key-Exchange Based Key Distribution

(75) In an alternate embodiment, the DiffieHellman (DH) key-exchange method is innovatively employed by the design for key distribution. Those skilled in the art will understand that DH is a method of securely exchanging cryptographic keys over a public channel. In a DH scheme the exchanging parties can derive a shared secret from a set of publicly exchanged keys. More specifically, the two parties each have a first half of a DH key or private key that is only privately known to them. The second half of the key is public and is exchanged over a non-secure or public channel between the parties. Then, each party, by applying its private DH key to the public DH key of the other party, can derive the same key or shared secret. The derived key/secret is thus never exchanged on the public channel and is still commonly derived by the two parties. Such a derived key is typically used for session keys for symmetric encryption in the industry.

(76) As an innovation over the prior art in the present embodiment employing a DH scheme, gateway 104A and devices 108 first generate their DH key with public and private halves/portions. Such DH keys can be generated by key server 204 which then issues and sends the keys to the gateway and the devices. Alternatively, the DH key may be generated locally on the gateway and/or the devices. In any case, the gateway then broadcasts the public portion of its DH key along with DH parameters (including prime number P and generator number G) to all the devices.

(77) Each device receives the public key of the gateway along with the DH parameters and then apply their respective second half or private keys to arrive at the same shared key/secret between gateway 104A and all of devices 108A, 108B, . . . . The shared secret or key thus obtained is the unique EDK of the device. Each device, such as device 108D, then derives its unique DEK from the EDK per below explanation. It then encrypts its IoT messages with the DEK and then sends the encrypted messages along with its public DH portion/key to gateway 104A.

(78) Since the gateway has access to its private DH key, it also derives the same share secret or EDK by applying is private DH key to the public DH key of the device received with the message. It then also derives the DEK of the device from the EDK as explained further below, and can then decrypts encrypted message of device 108D. For efficiency and other reasons, in some variations, the devices may send their DH keys to the gateway only periodically or on-demand, and not with each individual message. In these variations, the gateway would need to store or “remember” the EDK or the public DH key of the device for the requisite period of time.

(79) The DH key-exchange method based key distribution scheme of the present embodiment is shown in FIG. 6. The drawing figure of embodiment 380 shows that gateway 104A broadcasts its public DH key and DH parameters to all the devices as shown by bubble 384. The devices then derive the shared secret key using their respective private DH keys and the public DH key of the gateway. The shared secret is their EDKs from which they derive their DEKs. They then send their respective public DH keys to the gateway along with their IoT data messages encrypted with the respective DEKs. The above is indicated by bubble 386 in FIG. 6. Then, as shown by bubble 388, the gateway is able to recover the shared secret or EDKs of the devices using its private DH key and the public DH keys of the devices. It then derives the DEKs of the devices from the EDKs for decrypting the IoT data from the devices per above explanation.

(80) It is important that the devices are first properly authenticated in order to avoid a man in the middle (MITM) attack. In such an attack, a malicious device on network 110 may obtain the public DH key and DH parameters broadcasted by the gateway to derive an EDK. It may then impersonate as a legitimate device by sending its IoT messages and EDK to gateway 104A and start communicating with it. To avoid such an MITM attack, any of the authentication schemes described earlier may be used to ensure that all devices on network 110 are legitimate and authenticated devices.

(81) Individual Shared Secret-Based Key Distribution

(82) In still another embodiment, gateway 104A calls key manager 204 to generate a symmetric wrapping key per device. The gateway then sends the wrapping key and the device ID to the device. The device generates a per-message DEK by applying a key derivation function (KDF). Those skilled in the art will appreciate that a KDF derives one or more secret keys from a secret value such as a master key, a password, or a passphrase using a pseudorandom function. In the present embodiment, such a KDF is given by the following equation:
per−message DEK=KDF(wrapping key,Device ID,counter)  Eq. 1

(83) In Eq. (1) above, wrapping key is the wrapping key generated by the key server, and device ID is sent by gateway 104A to the device, such as device 108C of FIG. 2-4, along with the wrapping key. The device uses its own counter and generates a per-message DEK by applying Eq. (1) above. It then encrypts each IoT data message with its DEK to obtain the encrypted IoT message which it then sends to the gateway along with its device ID and the counter value for the message in plaintext form. When the gateway needs to decrypt encrypted an IoT data message from device 108C, it calls key manager/server 204 with the device ID for device 108C and obtains the same wrapping key for the device. It then also applies Eq. (1) above with the wrapping key, device ID and counter values received in the message. It thus arrives at the same individual shared secret or per-message DEK and is consequently able to decrypt the IoT message.

(84) The key distribution scheme of the present embodiment is shown in FIG. 7. The drawing figure of embodiment 390 shows that gateway 104A first obtains the wrapping keys for the devices from key server 204 as indicated by bubble 392. Then, as shown by bubble 394, the gateway sends the wrapping keys and device IDs of individual devices to the respective devices. The devices derive their per-message DEKs by applying Eq. (1) above.

(85) They then encrypt each IoT data message with its corresponding DEK to obtain encrypted IoT data message which they send to the gateway along with their device ID and respective counter value. This is shown by bubble 396. Then, as shown by bubble 398, the gateway is able to recover the DEK for each IoT data message by applying Eq. (1) above and is then able to decrypt the IoT data message as needed.

(86) In an exemplary implementation of the present embodiment, the device ID in the above embodiment is simply the MAC address of the device. In such an implementation, the gateway does not need to send the device ID to the devices because the devices know their own MAC addresses. They then send their MAC addresses to the gateway along with counter values and encrypted IoT messages per above explanation.

(87) Key Derivation, Encryption and Data Encoding:

(88) Let us now look in detail at how devices of FIG. 1-2 and above teachings are able derive the DEK from an EDK as provided in some embodiments, and then encrypt/decrypt IoT data 114 and encode it for transmission on network 110 according to the present design. Based on the above teachings, it should be clear by now as to how each edge device 108 possesses its exchanged data key (EDK) from key server 204 using one of the aforementioned key distribution schemes. As already noted, each device derives its data encryption key (DEK) or simply data key from its EDK, and it ultimately uses its DEK to encrypt IoT data 114. In one embodiment however, Eq. (1) was employed by both gateway 104A and devices 108 to derive a per-message DEK without requiring an EDK from the key server.

(89) Thus, in some aspects of the present the encrypt-decrypt-once design, a DEK was used by the devices to encrypt all of their IoT data messages. However, in another embodiment employing Eq. (1) above, there was a per-message DEK that was used by the devices to encrypt each IoT data message. Furthermore, many viable approaches were taught above for authentication and provisioning, including enrollment and introduction, of the devices on network 110 at IoT site 102.

(90) Regardless of the specific authentication/provision and key distribution scheme used, in the embodiments that employ EDKs issued from the key server, the devices derive their DEKs using a key derivation function (KDF). The KDF uses an initialization vector (IV) or a counter or salt that ensures that each derived DEK is unique.

(91) In one exemplary implementation, such a derivation scheme for the DEKs is given by the following equation:
DEK=HKDF(EDK,salt)  Eq. 2

(92) In the above example, HKDF is a KDF based on HMAC, referred to as HMAC-based KDF per the prevailing techniques, and salt is a random number generated by the device at the time the DEK is derived by Eq. (2) of the present design above. Salt is then transmitted with the encrypted messages of the device as will be further explained below. As another security aspect of the present design, the DEKs are never stored by the devices, but rather only generated and kept in memory. This way, any chances of them being compromised from a secondary/off-line storage are eliminated.

(93) The encryption regime employed by the devices to encrypt their IoT data by DEK is authenticated encryption because it simultaneously provides confidentiality, integrity, and authenticity assurances on the encrypted data. Then, the converse process of authenticated decryption only decrypts encrypted or ciphertext data if the integrity of the encrypted IoT data is verified, and fails otherwise. After the devices have encrypted their IoT data, they may temporarily store the data locally in its encrypted/ciphertext form, before transmitting it to the gateway(s)/recipient(s) per the teachings provided herein.

(94) Preferably, the authenticated encryption regime employs an advanced encryption standard (AES) in Galois/counter mode (GCM) mode of encryption. The advantages of such a GCM mode of symmetric key cryptographic ciphers include high efficiency and performance. Furthermore, AES/GCM provides authenticated encryption/decryption as will be explained further below. Such an authenticated encryption process is expressly visualized in FIG. 8 for an i-th IoT data message M.sub.i shown by reference numeral 402. Together such IoT data messages M.sub.i or simply IoT message M.sub.i constitute IoT data 114 of prior teachings as also shown in FIG. 8. The encryption operation on message M.sub.i with DEK 406 is indicated by ENC and marked by reference numeral 400. This authenticated encryption operation can be conveniently expressed by the following equation:
ENC(DEK,Counter.sub.i,M.sub.i,AAD)=C.sub.i and T.sub.i,  Eq. 3A

(95) In Eq. (3A) above T.sub.i is the authentication tag produced by the encryption step ENC and which may be later used by gateway 104A of FIG. 1-7 to verify the integrity of the ciphertext/encrypted IoT data message C.sub.i for authenticated decryption. Here AAD stands for additional authenticated data, and is obtained by preferably performing a secure hash algorithm, such as Sha-256, as shown by reference numeral 401, on fields: protocol version (PVer), sender ID (SID), key ID (KID), salt, counter (Ctr) and header (Hdr) of encrypted/ciphertext IoT message C.sub.i. These fields will be explained in detail further below.

(96) AAD along with authentication tag T.sub.i represents the metadata of encrypted IoT message C.sub.i as shown by reference numeral 410. The metadata is transmitted on network 110 of FIG. 1-2 along with each encrypted IoT data message C.sub.i as a combined transmitted message *C.sub.i shown by reference numeral 408 in FIG. 8. To avoid unnecessary repetition and confusion, we may simply refer to both messages C.sub.i and *C.sub.i as encrypted IoT messages knowing the distinction that the former is just the ciphertext equivalent of plaintext IoT message M.sub.i and the latter is a combination of C.sub.i and encoded metadata fields per below explanation. As such, we may only draw the distinction between C.sub.i and *C.sub.i as and when needed.

(97) Authenticated encryption of Eq. (3A) is an example of authenticated encryption with associated data (AEAD) operation afforded by GCM. Such an encryption simultaneously provides confidentiality, integrity, and authenticity assurances on the data being encrypted.

(98) The converse process of decryption is illustrated in FIG. 9, which contains many of the elements and their reference numerals from FIG. 8. Decryption operation is indicated by DEC marked by reference numeral 450 and since DEK 406 is symmetric, it is performed by inverting the order of operation and applying the authentication tag T.sub.i in Eq. (3A) as follows:
DEC(DEK,Counter.sub.i,C.sub.i,AAD,T.sub.i)=M.sub.i if the inputs are authentic,FAIL otherwise.  Eq.3B

(99) The transmission of IoT data from the devices on the network takes place in messages. Now, let us look at how the metadata fields are encoded in encrypted IoT messages *C.sub.i for transmission on IoT network 114 of FIG. 1-2 and prior teachings based on the instant principles. Each transmitted IoT data message *C.sub.i has type length value (TLV) encoding format. Specifically, and in one exemplary embodiment, each field in message *C.sub.i has a TLV encoding format and as provided in Table 1 below.

(100) TABLE-US-00001 TABLE 1 Field Name Type Protocol Version (PVer) 0x01 Sender ID (SID) 0x12 Key ID (KID) 0x22 Salt 0x32 Counter (Ctr) 0x42 Encrypted ciphertext (C.sub.i) 0x52 Tag (Ti) 0x62

(101) In the above example, Type is two-byte value from 0x00 to 0xFF (Hexadecimal). The first byte 0x0, 0x1, 0x2 . . . 0x6 of Type column above represents the field ID, such as PVer, SID, KID, . . . , T.sub.i respectively. The second byte represents whether the corresponding field is an integer or a vector. Here 0x01 represents an integer and 0x02 represents a vector. Vectors are simply raw vectors of any length. Thus, in Table 1 above field PVer is an integer of a fixed length and encoding, such as four-byte unsigned value in network byte order. A vector consists of a length of type integer followed by the actual data. Thus, vector fields SID, KID, . . . each will have a four-byte unsigned integer value representing the length of the data, followed by the data itself.

(102) Now let us look at the various fields of our transmitted IoT data message *C.sub.i in further detail. 1. Protocol version (PVer). Protocol Version number or version field or attribute is used for tracking the version number or updates of the protocol being deployed for a given implementation of the present design. Different versions/updates of the protocol of the present design may signify varying encryption algorithms of various bit sizes for Eq. 3A and Eq. 3B above. Such versions may also include authenticated encryption/decryption algorithms other than GCM and any successor algorithm(s) to AES, as well as other suitable algorithms. 2. Key ID (KID). Key ID is an identifier for the EDK. This is the number assigned by key manager/server 204 of FIG. 1-2 and earlier explanation to the EDK issued to a device and is sent by the key server along with the EDK to the device. In one implementation, the key server may first hash the actual identification number of the EDK by an algorithm such as Sha-256 and then optionally performing truncation on it, prior to its transmission to the device. The purpose of sending this field in the metadata of transmitted message *C.sub.i is to ensure that the recipient/gateway also has the knowledge of the ID of EDK employed by the device to derive its DEK. 3. Salt. Salt is the salt used by the device to derive its DEK per Eq. (2) above and related explanation, and in one implementation is exemplarily a random number generated at the time of the derivation of the DEK. Since key ID of the EDK (KID) and the salt is transmitted with the message, the gateway/recipient is able to generate the same DEK as the device had used to encrypt its data by applying Eq. (2) above. 4. Counter (Ctr). Counter is an initialization vector used for each invocation of authenticated encryption ENC 400 of FIG. 8. It is a monotonically increasing number and is incremented each time a new message *C.sub.i is sent by the device. When/if a new DEK is derived by the device, for example, in the embodiment employing a unique DEK per message *C.sub.i, then the counter may be reset. If two processes or threads of an implementation use the same DEK then they must ensure they use unique counters. Therefore, it is preferable to derive a different DEK for each process or thread. 5. Encrypted/ciphertext message C.sub.i. This is the ciphertext data produced by the device by applying Eq. (3A) above on plaintext IoT message M.sub.i. 6. Tag (T.sub.i). Authentication tag T.sub.i is the authenticated encryption tag by applying GCM as expressed in Eq. (3A) above. As already noted, it is used by the recipient/gateway to verify the integrity and authenticity of transmitted message *C.sub.i by applying Eq. (3B) above during authenticated decryption. 7. Encrypted message header (Hdr). This is the TLV header containing the types, lengths and values of all the above fields 1-6, except the Hdr field itself.

(103) As noted earlier that AAD in Eq. (3A) above is provided to encryption operation ENC 400 of FIG. 8 by computing a Sha-256 hash of the various metadata fields of transmitted message *C.sub.i. More specifically,
AAD=Sha−256(PVer,SID,KID,salt,Counter.sub.i,Hdr),  Eq. 4

(104) Sha-256 in Eq. (4) above is performed on the above-specified fields in their TLV encoded form. This computation is performed in IoT devices 108 in their memory. In other words, the computation of Eq. (4) above is performed after the specified fields have been TLV-encoded in the memory. This is to ensure that AAD is computed on the fields in their final form before transmission. The fields themselves are transmitted in their plaintext and unencrypted form. That way, when recipient/gateway receives transmitted message *C.sub.i, it is able to compute the same hash by applying Eq. (4) above and then providing that as input to Eq. (3B) for decryption. As a result, the authenticated decryption of Eq. (3B) will only succeed if all of the metadata of transmitted IoT message *C.sub.i as well as encrypted/cyphertext message C.sub.i itself has not been tampered with.

(105) In various embodiments above, the gateway at an IoT site was used as the key recipient of encrypted IoT data sent by the IoT devices. In related variations and as already noted above, the target recipient of such IoT data may be any other server or system local to the IoT site or at a corporate data center, depending on the specific implementation. A variety of such implementations can benefit from the encrypt-decrypt-once benefits of the present design based on the above teachings.

(106) The above-taught techniques provide effective means for a person of average skill to secure an IoT infrastructure in an efficient and end-to-end manner by taking advantage of the present encrypt-decrypt-once technology. Thus, IoT data 114 of FIG. 1-2 on network 110 on site 102 is encrypted only once and remains encrypted throughout the various stages of its lifecycle until its final consumption. As a result of the present design, any exposure to IoT data 114 in its plaintext form from its inception to its consumption is thus prevented. Furthermore, the techniques also provide technological efficiencies by performing encryption only once and thereby reducing the burden on computing and other resources of the IoT infrastructure.

(107) In view of the above teaching, a person skilled in the art will recognize that the methods of present invention can be embodied in many different ways in addition to those described without departing from the principles of the invention. Therefore, the scope of the invention should be judged in view of the appended claims and their legal equivalents.