Methods, devices, and systems for secure communication over a network

Abstract

A method, device and system for secure communication over a network, the method comprising: receiving a data packet from a first device, the data packet comprising an encrypted data portion and a metadata portion, the metadata portion comprising a plaintext portion and removable metadata, the removable metadata comprising a network access code authenticable by means of a network access key; validating the data packet, wherein validating the data packet comprises authenticating the network access code using the network access key; removing the removable metadata from the data packet after validating the data packet, thereby altering the data packet; and transmitting the altered data packet to a second device. The system comprises the first device, the second device and a third device. The third device can comprise a receiver and a transmitter, and a validator comprising a processor and a memory.

Description

Technical Field

[0001] This disclosure relates to the field of secure communication over a network, and more particularly to communication involving end-to-end (E2E) security. More specifically, this disclosure concerns communication between a first device (e.g., a cloud server) and a second device (e.g., a constrained node) via a third device (e.g., a gateway and / or proxy to the second device). Background Technology

[0002] With the establishment and widespread implementation of various technologies and devices that contribute to the development of the Internet of Things (IoT), there is an increasing need to develop methods and systems for secure communication on the networks to which these devices reside. Within these networks, there are typically constrained end nodes. According to RFC 7228 (Borman et al., May 2014, Retrieved from...),...<https: / / tools.ietf.org / html / rfc7228#section-2.1> A constrained node can be a node in which certain characteristics that are obviously unattainable for an internet node are impossible due to factors such as cost and / or constraints on characteristics such as power and energy. In the aforementioned network, one of the devices as part of the network can be, or effectively acts as, a constrained end node and can be connected to the cloud server via an intermediary proxy / gateway. The link between the proxy / gateway and the server is typically unconstrained, and the gateway / proxy usually has no obvious power and bandwidth constraints. However, severe power and bandwidth constraints are typically present at the end node. When data packets are encrypted E2E from the server to the constrained end node, the gateway often becomes a blind forwarder of information. If the gateway connects the constrained network to the internet, the entire network is highly vulnerable to denial-of-service (DoS) attacks and replay attacks using man-in-the-middle techniques, which can cause congestion and thus attack the constrained network.

[0003] Several security protocols are used as means to at least partially prevent the aforementioned attacks and provide end-to-end security. Two known protocols are (D)TLS [(Datagram) Transport Layer Security] and OSCORE (Object Security for Constrained RESTful Environments). OSCORE is a lightweight E2E security protocol; for a description of OSCORE, see: Selander, G., Mattsson, J., Palombini, F. and Seitz, L., July 2019. “Object security for constrained RESTful environments (oscore)”, ISSN: 2070-1721. OSCORE has a data-metadata concept, according to which data packets include encrypted data from source to destination (E2E security) and also include metadata in plaintext form. The use of OSCORE to provide E2E security for constrained nodes / networks and to improve the robustness and efficiency of nodes is a recent development. Summary of the Invention

[0004] Embodiments of this disclosure provide improved methods, apparatus, and systems for secure communication over a network.

[0005] These implementations include a method for secure communication over a network. The method includes: receiving a data packet from a first device, the data packet including an encrypted data portion and metadata, the metadata portion including a plaintext portion and removable metadata, the removable metadata including a network access code authenticable using a network access key; verifying the data packet, wherein verifying the data packet includes authenticating the network access code using the network access key; after verifying the data packet, removing the removable metadata from the data packet, thereby modifying the data packet; and sending the modified data packet to a second device.

[0006] These implementations also include a third device for secure communication over a network. The third device includes: a receiver configured to receive data packets from a first device, the data packets including an encrypted data portion and metadata, the metadata portion including a plaintext portion and removable metadata, the removable metadata including a network access code authenticable using a network access key; a verifier coupled to the receiver and including: a memory storing the network access key and instructions; and a processor configured to execute instructions to cause the verifier to verify the received data packets by: authenticating the network access code using the network access key; and removing the removable metadata from the data packets to modify the data packets; and a transmitter coupled to the verifier and configured to receive the modified data packets and transmit the modified data packets to a second device.

[0007] These implementations also include a system for secure communication over a network. The system includes: a second device configured to receive modified data packets from a third device; and a third device comprising: a receiver configured to receive data packets from a first device, the data packets including an encrypted data portion and metadata, the metadata portion including a plaintext portion and removable metadata, the removable metadata including a network access code authenticable using a network access key; a verifier coupled to the receiver and including: a memory storing the network access key and instructions; and a processor configured to execute instructions to cause the verifier to verify the received data packets by: authenticating the network access code using the network access key; and removing removable metadata from the data packets to modify the data packets; and a transmitter coupled to the verifier and configured to receive the modified data packets and transmit the modified data packets to the second device. Attached Figure Description

[0008] The advantages and features of this disclosure will become more apparent from the following description, which explains certain preferred embodiments of the disclosure with reference to the accompanying drawings without limiting the main claims.

[0009] Figure 1 It is a schematic diagram of a system according to one aspect of this disclosure;

[0010] Figure 2 This is a flowchart of a method according to other aspects of this disclosure;

[0011] Figure 3 This is a flowchart that is part of a method according to one aspect of this disclosure;

[0012] Figure 4 This is a flowchart that is part of an alternative method according to one aspect of this disclosure;

[0013] Figure 5A The structure of an example data packet transmitted from a first device to a third device in a method according to one aspect of this disclosure is illustrated schematically;

[0014] Figure 5B The structure of an example data packet transmitted from a first device to a third device in a method according to one aspect of this disclosure is illustrated schematically;

[0015] Figure 5C The structure of an example data packet transmitted from a first device to a third device in a method according to one aspect of this disclosure is illustrated schematically;

[0016] Figure 5D The diagram schematically illustrates the structure of an example change data packet sent from a third device to a second device, the change data packet being from... Figure 5C This is generated by removing removable metadata from data groups;

[0017] Figure 6A This is a schematic diagram illustrating an example of a third device according to another aspect of this disclosure;

[0018] Figure 6B This is a schematic diagram of another example of a third device according to one aspect of this disclosure. Detailed Implementation

[0019] The combination of OSCORE and (D)TLS can be used to provide network authentication and verification without compromising E2E security, but this may lead to performance degradation at gateways / agents. Therefore, there is a need to provide a secure and encrypted communication over the network (especially networks that include constrained nodes) without significantly degrading performance at gateways / agents or end nodes.

[0020] This disclosure provides secure and encrypted communication over networks (particularly networks including constrained nodes) without significantly increasing bandwidth and power requirements or degrading performance. Advantageously, the solutions provided herein can be implemented using network hardware (e.g., using gateways) without requiring powerful and costly systems; relatively small and inexpensive hardware can protect the entire network.

[0021] According to a first aspect of this disclosure, a method for secure communication over a network is provided. The method includes: receiving a data packet from a first device, the data packet including an encrypted data portion and metadata, the metadata portion including a plaintext portion and removable metadata, the removable metadata including a network access code authenticable using a network access key; verifying the data packet, wherein verifying the data packet includes authenticating the network access code using the network access key; after verifying the data packet, removing the removable metadata from the data packet, thereby modifying the data packet; and sending the modified data packet to a second device.

[0022] In some implementations, the network may include components and channels, wherein communication is wireless and / or via wired connections. Communication may include the sending and receiving steps of the method.

[0023] In some implementations, removable metadata may be in plaintext form or include plaintext portions (a portion of plaintext). The term "plaintext" can be interpreted as data (i.e., information) sent or stored without encryption ("in ordinary text"). The network access code and / or the entire removable metadata may also be encrypted (translated into ciphers), and therefore, a network access key may be required to decrypt (break) the network access code and / or decrypt (break) the entire removable metadata (when the removable metadata is encrypted (translated into ciphers)).

[0024] As described herein, the third device can be provided as a gateway, but alternatively, it can be a proxy device. Similarly, the third device can be used as a proxy to the second device. Furthermore, the third device can be used as both a gateway and a proxy to the second device. In the latter case, the gateway (i.e., the gateway device) can be configured to perform both proxying and protocol conversion.

[0025] It is understood that, within the context of this disclosure, the encrypted data portion and the plaintext portion of a data packet can be designated for reception by a second device, wherein the encrypted data portion will be decrypted. Therefore, the method of the first aspect of this disclosure can further include: receiving a modified data packet sent from a third device at the second device. Similarly, the method can further include: decrypting the encrypted data portion at the second device. The modified data packet may include the encrypted data portion and may also include a plaintext portion designated for reception by the second device. The modified data packet does not include removable metadata, which, according to this method, is removed from the data packet, thereby modifying the data packet when (after) authentication of the network access code is performed at the third device.

[0026] Similarly, consider optionally providing the second device with the encryption key required to decrypt the encrypted data portion of the data packet. Providing the encryption key may include deriving the encryption key from a specific trusted source (preferably a specific hardware root of trust), or may include pre-sharing or negotiating an encryption key between the first and second devices that allows decryption of the encrypted data portion of the data packet, i.e., the encryption key required to decrypt the encrypted data portion of the data packet. Pre-sharing or negotiating the encryption key may include the first and second devices communicating between them via the same network sending the data packet and the modified data packet, or via different networks or different communication channels / links.

[0027] The following features directly contribute to increasing resource efficiency in the network and the second device (especially when the second device is a constrained node, i.e., a constrained communication node): namely, authenticating the network access code for verifying data packets at the third device (e.g., at the gateway) and removing the metadata portion including the code at the third device. The first aspect is having structured original data packets so that they can be authenticated at the gateway; the second aspect is authenticating data packets at the agent / gateway; and the third aspect is modifying the original packets so that their modified form is lightweight and compatible with any bandwidth and power limitations of the second device. These aspects allow the use of a third device to protect the second device and the entire communication network from malicious attacks that may attempt to exploit these limitations. This is a unique aspect of this disclosure because in existing networks, gateways are typically blind forwarders of information. Furthermore, since data packets are authenticated / authenticated at the third device (e.g., at the gateway) in this method, this allows for the possibility of securely accumulating or queuing these data packets at the third device before forwarding them to the second device. This can be useful when a second device temporarily ceases communication with a third device and / or the rest of the network due to power limitations or its specific functions, and / or when the second device is temporarily powered off or enters a sleep or low-power mode. The latter is common in IoT configurations. For example, when the second device is a relatively small module including sensors (such as temperature sensors), it often temporarily enters a sleep mode to conserve power. Therefore, the method of the first aspect of this disclosure may include queuing multiple data packets at the third device. Furthermore, the method may include modifying multiple data packets at the third device in the manner described above, resulting in multiple modified data packets that can be transmitted / sent from the third device to the second device when the second device communicates with the third device (e.g., when the second device exits sleep mode).

[0028] Based on the foregoing, it will now be understood that this disclosure considers the scenario where the second device can exit and / or enter sleep mode. Similarly, this disclosure considers the scenario where the second device can exit sleep mode and contact the third device. Furthermore, the third device can send queued packets to the second device, preferably after or at the time the second device contacts the third device as described above. As further explained below, data packets may include expiration times. If and when data packets are queued on the third device and the data packets include expiration times (or more than one expiration time), it is considered that the third device can check whether the expiration times (or more than one expiration time) have passed. After checking that the expiration times (or more than one expiration time) have not passed, the third device can send the queued data packets to the second device. Preferably, the third device can obtain the current time via the first device. In a non-binding example, the first device is a cloud server and the third device obtains the current time from the cloud server. Similarly, the third device can have its own clock. In a non-binding example, the third device has a GPS clock that provides the time to the third device.

[0029] To reduce the possibility of unauthorized or malicious third parties intercepting and verifying network access codes for data packets, the network access key required for verification can be provided to a third device (e.g., a gateway) in a trusted and secure manner. Therefore, in some embodiments, the method of the first aspect of this disclosure may further include: providing a network access key to a third device, and providing the network access key may include at least one of the following:

[0030] - Derive the network access key from a trusted source (preferably a hardware root of trust); or

[0031] - Pre-share network access keys between the first device and the third device; or

[0032] - Negotiate a network access key between the first device and the third device.

[0033] The aforementioned hardware root of trust can be connected to or included in a third device. Similarly, the hardware root of trust can have a secure environment and can be configured to generate keys, protect keys, and perform cryptographic functions within the secure environment. Likewise, the source of trust can be a root of trust comprising hardware and / or software and / or firmware components.

[0034] The aforementioned pre-sharing or negotiation of the network access key between the first and third devices can be performed using a device that communicates and exchanges information between the first and third devices via the same network or network channel / link used for sending data packets, or via different networks or different channels / links. Furthermore, the following scenario is considered: the first and third devices can be connected via a secure communication channel (link) for pre-sharing and / or negotiating the network access key before or during transmission via a network of data packets or a network of data packet sets. The secure communication channel can be part of a separate network in which communication signals are exchanged wirelessly and / or via a wired connection. Similarly, the network access key can be manually provided or entered into the third device, or provided or entered into the third device by means of connecting an information storage medium containing the network access key to the third device. For example, the information storage medium can be a magnetic storage medium or an optical storage medium (e.g., an optical disc).

[0035] Data packets may contain time-sensitive information that makes the data packet available only if it is received at a third device within a specific time period after the data packet is sent by the first device. The time-sensitive information may be an expiration time. The time-sensitive information may be part of the metadata portion, or preferably part of removable metadata. Therefore, the metadata portion (preferably removable metadata) includes an expiration time. In a non-limiting example, an expiration time is used because the encrypted data portion of the data packet to be decrypted at the second device contains a set of information or instructions to be received and / or executed by the second device within a specific time period. In another non-limiting example, an expiration time exists to discard data packets containing information that becomes obsolete after the expiration time for purposes related to secure communication. In yet another non-limiting example, an expiration time exists as a means at the third device to check whether communication of data packets from the first device to the third device has not been delayed due to unwanted interception of the data packets by a malicious or unauthorized third party. Therefore, in the method according to the first aspect of this disclosure, the metadata portion (preferably removable metadata) may include an indication of an expiration time, and verifying the data packet may include verifying at a third device whether the expiration time has passed, and discarding the data packet if the expiration time has passed. Discarding the data packet may include deleting the data packet, or storing the data packet for further processing and / or record keeping. Similarly, verifying whether the expiration time has passed may include comparing the expiration time with the current time of the first device. When the first device is a server (e.g., a cloud server), the current time of the first device may be the server time. Therefore, the method may include providing the current time of the first device to the third device. This provision may be achieved by transmitting the time of the first device from the first device to the third device via the same network that sent the data packet or via another network such as the aforementioned different network / channel, wherein the first device and the third device may pre-share or negotiate a network access key via the same network or the other network. It should be noted that the aforementioned expiration time may be in the form of a timestamp and an authentication code for the data packet. The network access code (NAC) may be a key message authentication code (MAC) based on the network access key. NAC can be created / verified by a first and a third device, as these devices may possess a Network Access Key (NAK). Similarly, the authentication code can be a digital signature. The digital signature can be calculated from the Network Access Key and metadata information (e.g., expiration time).

[0036] As described above, it can be understood that data packets may contain verifiable timing information used to check with a third device whether the data packet was received within a certain timeframe. Similarly, including timing information in the data packets constituting a set of data packets allows for checking that each or any one of the data packets in the set was sent and / or received in the correct chronological order, or that it was sent and / or received with a desired chronological proximity relative to the times when other data packets in the set were sent by the first device or received by the third device. This timing information may be a timestamp. A timestamp may indicate the moment when a data packet was created or appeared in or was sent by the first device. Therefore, this moment can be indicated by the timestamp based on the first device time. In relation to the first device time, the first device may include a clock indicating the first device time or may be connected to a clock indicating the first device time, and the timestamp may indicate the first device time given by the clock at the moment the timestamp was created. In some embodiments, when verifying a time packet at a third device, the time given by the clock is the aforementioned current device time. In summary, the verifiable timing information may optionally include a sequence number. Sequence numbers can be used as an indication of the time a data packet is sent, received, or generated relative to other data packets. Some non-constrained examples of sequence numbers could be: i) numbers in a sequence of numbers where each number is assigned to a data packet in a set of data packets that are consecutively generated or sent / transmitted by a first device; or ii) numbers in a sequence of numbers where the numerical difference (ΔN = N2 - N1) between any two numbers (e.g., N1 and N2) is linearly related to a specific time period (e.g., Δt) (e.g., via the relation ΔN = a * Δt, where a is a constant). In general, since sequence numbers can serve to associate data packets with a set of data packets, or to identify the (sequential) position of a data packet relative to other members of the set (in the latter case, the sequence number is valuable in the specific context associated with the set of data packets), the sequence number, or the entire sequence containing that number, can be pre-shared or negotiated between the first and third devices so that the context in which the sequence number is evaluated can be known at the third device. An alternative scenario is considered, in which the first device and the third device can negotiate, share, or exchange starting sequence numbers between them through any mechanism. The starting sequence number can be the sequence number of the first data packet in a set of data packets to be communicated between the first and third devices. The sequence number can increment with each transmitted data packet in the set. The first data packet can be the first data packet in the set transmitted between the first and third devices. Therefore, preferably, it is conceivable that after the first data packet has been transmitted between the first and second devices, the corresponding sequence numbers of data packets in the set transmitted between the same devices can be incremented, for example, relative to the first sequence number.Similarly, pre-shared or negotiated sequence numbers can be used to anticipate receiving data packets or sets of data packets at a third device.

[0037] In summary, in the method of the first aspect of this disclosure, the removable metadata may include verifiable timing information, which includes timestamps or sequence numbers. In the latter case, the method may further include pre-sharing or negotiating sequence numbers between the first device and the third device. When the metadata portion includes sequence numbers that can indicate the order of arrival of data packets at the third device, or the order of transmission of data packets from the first device, or the order of creation of data packets, pre-sharing or negotiating sequence numbers between the first device and the third device is primarily considered, or preferably, starting a sequence number. The creation may occur at the first device or at a data packet generating device connected to and communicating with the first device. Similarly, when the removable metadata includes verifiable timing information containing sequence numbers, the method may include pre-sharing or negotiating at least one of the following between the first device and the third device: a rule or recursive relation that defines a sequence containing sequence numbers; a first sequence number in the sequence; or an initial term of the recursive relation. A rule (also commonly referred to as a recursive relation) may define a sequence as a sequence of numbers. Some non-binding examples of the rules are: all numbers in the sequence are prime numbers; any number in the sequence differs from the previous number in the sequence by a fixed value, such as -1 or +1; each number a in the sequence... n+1 With the previous number a in the sequence n The relationship is a n+1 =b*a n +c, where n is an integer ≥ 1, b and c are integers, and a1 corresponding to n = 1 is the first sequence number of the sequence. In the latter example, some unconstrained examples of the initial terms of the recursive relation are: b = 1 or 2; c = 1 or 2; a1 = 931. If two devices negotiate to define the rules or recursive relation of the sequence, the negotiation may include negotiating the sequence description. Two unconstrained examples of the sequence description are: prime numbers; and prime numbers starting from 11. Advantageously, the method may include: pre-sharing or negotiating the sequence description between the first and third devices when the removable metadata includes verifiable timing information containing sequence numbers, the sequence description including the sequence number of the data group and the first number of the sequence. Thus, in the unconstrained example, the method may include negotiating between the first and third devices that the sequence is a prime number and the first number of the sequence is 11. In the latter case, the sequence number of the first data group is 11, the sequence number of the second data group is 13, the sequence number of the third data group is 17, and so on.

[0038] The optional verifiable timing information described above can be checked or verified to determine at the third device whether a data packet is valid or permitted, and thus whether the data packet should be modified and subsequently transmitted to the second device (or not transmitted to the second device). Checking or verifying the verifiable timing information allows the third device to block any data packets that are not received on time, or insecure data packets that were not sent by the first device. For example, such insecure data packets may have been sent by a malicious third party as part of an attack. If it is determined that a data packet is invalid or not permitted, the data packet can be discarded. Preferably, discarding a data packet includes any of the following: deletion, archiving (placing / registering in a record or list), or reporting / sending the data packet or a portion thereof (e.g., timestamp or sequence number) to a security device / server or authority. Therefore, in the method of the first aspect of this disclosure, where the removable metadata of the data packet includes verifiable timing information, the method (especially the step of verifying the data packet) may also include verifying (checking) the verifiable timing information to determine whether the data packet is valid, and discarding the data packet at the third device when it is determined that the data packet is invalid. In the latter case, two options are considered: when the verifiable timing information includes a timestamp, verifying the verifiable timing information may include comparing the timestamp with the time of the first device; when the verifiable timing information includes a sequence number, verifying the verifiable timing information may include comparing the sequence number with an expected sequence number. The expected sequence number can be inferred based on negotiations that may occur between the first and third devices regarding a sequence including the aforementioned sequence number. Therefore, in the context of determining whether a data packet is valid, verifying the network access code can advantageously supplement the verification of the verifiable timing information. Similarly, verifying or checking the verifiable timing information may include: verifying the network access code using a network access key; checking whether the expiration time has passed and / or checking whether the timestamp or sequence number is valid or expired. Determining whether a data packet is valid can be interpreted as determining whether the data packet is permitted or associated with the second device. Similarly, determining that a data packet is invalid can be interpreted as meaning that the data packet is not permitted or associated with the second device.

[0039] The aforementioned timing information and sequence number can serve as the basis for determining whether a data packet is permitted (or not permitted). Determining the permissibility of a data packet is most relevant when multiple data packets are sent at a first device and received at a second device, and the sequence numbers of the data packets belong to the same or different sequences. Therefore, in the method of the first aspect of this disclosure, the verifiable timing information of the data packet may include the sequence number, and the method may further include: receiving another data packet at a third device having a corresponding (removable) metadata portion, the corresponding (removable) metadata portion having another sequence number belonging to a specific number sequence, and the data packet may be permitted when any of a)-d) below are true:

[0040] a) The sequence number of this data group is different from the sequence number of another data group.

[0041] If a) above is true, this may mean that the data packets received at the third device are permitted because they are not part of an attack that involves sending several data packets with the same sequence number to the third device.

[0042] b) The sequence number of the data group belongs to a specific sequence; and / or,

[0043] c) The sequence number of the data packet belongs to a specific sequence, and the sequence number and another sequence number are arranged in the sequence in the order that the data packet and the other data packet are received at the third device.

[0044] If c) and / or b) above are true, it may indicate that the data packet is permitted for the following reasons: because the data packet is expected at the third device; because the data packet is part of a set of data packets expected at the third device based on its number and the sequence to which the number belongs; because the data packet and another data packet are received consecutively and / or in order at the third device; and / or because the sequence and / or the sequence number (member) has been additionally pre-shared or negotiated between the first device and the third device.

[0045] (d) The sequence number of the data packet belongs to a specific sequence, and between receiving the data packet at the third device and receiving another data packet, a third data packet with a corresponding third sequence number that does not belong to the specific sequence will not be received at the third device.

[0046] If d) above is true, it may indicate that the data packet is allowed because its sequence number or the sequence to which the number belongs is not marked in red or associated with or marked as being related to a suspicious or malicious attack on the network or any first, second or third device.

[0047] The modified data packet (i.e., the data packet resulting from modifying the (original) data packet sent by the first device at the third device) can be (i.e., include / have the following structure) according to the OSCORE protocol. Therefore, the method of the first aspect of this disclosure is also contemplated and may include: providing an initial data packet according to the OSCORE protocol and including an encrypted data portion and a metadata portion, the metadata portion including removable metadata, before sending the data packet from the first device; and the method further includes: modifying the initial data packet by adding removable metadata, including a network access code capable of authentication by means of a network access key, to the metadata portion.

[0048] According to a second aspect of this disclosure, a third device for secure communication over a network is provided, which may be a gateway as mentioned above with respect to the first aspect of this disclosure. Therefore, the second aspect of this disclosure is a device that is or includes a third device (e.g., a gateway) for secure communication over a network. The third device includes: a receiver configured to receive data packets from a first device, the data packets including an encrypted data portion and metadata portion, the metadata portion including a plaintext portion and removable metadata, the removable metadata including a network access code capable of authentication by means of a network access key; a verifier coupled to the receiver and including: a memory storing the network access key and instructions; and a processor configured to execute instructions to cause the verifier to verify the received data packets by: authenticating the network access code using the network access key; and removing removable metadata from the data packets to modify the data packets; and a transmitter coupled to the verifier and configured to receive the modified data packets and transmit the modified data packets to the second device.

[0049] In some embodiments, the verifier may be circuitry for computation. Alternatively, the verifier may be a combination of systems or elements arranged in a computer or electronic device to perform the tasks described herein. In some embodiments, the verifier may include one or more processors and one or more memories storing instructions for performing the tasks specified herein.

[0050] The third device of the second aspect of this disclosure may have a transceiver configured to perform the functions of each of the aforementioned receivers and transmitters. When the third device includes a transceiver, it may exclude the aforementioned separate receivers and transmitters. Each of the aforementioned transceivers, receivers, and transmitters may be configured to connect to a network and wirelessly and / or via a wired connection to receive and / or transmit data packets.

[0051] The third device may further include a second receiver and / or a second transmitter and / or a second transceiver, the second receiver and / or the second transmitter and / or the second transceiver being used for pre-sharing and / or negotiating network access keys and / or optional timing information for the aforementioned data packets and / or the first device time, as further described above with respect to the method of the first aspect of this disclosure. The third device may include firmware and / or software required for the third device to be configured to perform functions during operation.

[0052] According to a third aspect of this disclosure, a system for secure communication over a network is provided. The system includes: a second device configured to receive modified data packets from a third device; and a third device comprising: a receiver configured to receive data packets from a first device, the data packets including an encrypted data portion and metadata portion, the metadata portion including a plaintext portion and removable metadata including a network access code authenticable using a network access key; a verifier coupled to the receiver and including: a memory storing the network access key and instructions; and a processor configured to execute instructions to cause the verifier to verify the received data packets by: authenticating the network access code using the network access key; and removing removable metadata from the data packets to modify the data packets; and a transmitter coupled to the verifier and configured to receive the modified data packets and transmit the modified data packets to the second device.

[0053] In some embodiments, within the system of the third aspect of this disclosure, the first device may be a cloud server and the second device may be a constrained node. Similarly, in the system, the third device may be a proxy to the second device. In summary, the system of the third aspect of this disclosure can be configured to perform the methods of the first aspect of this disclosure.

[0054] Figure 1 A schematic diagram of a system according to one aspect of this disclosure is shown. Figure 1 The system shown includes: a first device 1 (which is a server, specifically a cloud server), a third device 3, and a second device 2a. This particular system also includes additional devices 2b and 2c, which are functionally similar to the second device and, similarly, are constrained communication nodes communicatively connected to the third device 3. The third device 3 acts as a gateway and a proxy to the second device 2 and the aforementioned additional second devices 2b and 2c. Therefore, communication between the first device 1 and the second device 2 is mediated by the third device 3. These devices are interconnected via several network links 13, 32, 32b, 32c, 22b, and 22c, as follows: Figure 1 As shown. Any link can be wired or wireless.

[0055] Figure 2 A flowchart of a method according to one aspect of this disclosure is shown. Figure 2 The method shown includes the following steps:

[0056] - In step 1001, a data packet is sent from the first device to the third device. The data packet includes an encrypted data portion and a metadata portion, the metadata portion including removable metadata, which includes a network access code that can be authenticated using a network access key.

[0057] - In step 1002, data packets are received at the third device;

[0058] - In step 1003, the network access code in the removable metadata is authenticated, and the data packet is verified at the third device (by the third device);

[0059] - In step 1004, the data grouping is changed by removing removable metadata, thereby producing the changed data grouping;

[0060] - In step 1005, the modified data packets are sent from the third device to the second device;

[0061] -In step 1006, the modified data packet is received at the second device;

[0062] - In step 1007 (decryption), the encrypted data portion of the data packet is decrypted at the second device.

[0063] exist Figure 2 In the example, in step 1003, verifying the data packet and authenticating the network access code (NAC) at the third device includes: checking whether the NAC and another part of the optional removable metadata are valid, and continuing to modify the data packet in step 1004 only if the NAC or the other part is determined to be valid; if the NAC or the other part of the removable metadata is determined to be invalid, then continuing to discard the data packet in step 1009.

[0064] also, Figure 2 The example shown includes: in step 1008, providing a network access key to a third device; then, in step 1003, authenticating the network access key at the third device. Similarly, in Figure 2 In the example, removable metadata can advantageously include timing information.

[0065] same, Figure 2 The example shown includes: in step 1010, providing an encryption key to a second device, and then, in step 1007, at the second device, using the encryption key to decrypt the encrypted data portion of the data packet. Similarly, in Figure 2 In the example, sending the data packet from the first device to the third device in step 1001 may optionally occur after providing the data packet to the first device in step 1000. In step 1000, providing the data packet may be sending / inputting / transmitting the data packet to the first device, and / or preferably generating the data packet at the first device or in a data packet generating device communicatively connected to the first device. Therefore, preferably, the first device or alternatively the data packet generating device is configured to generate the data packet.

[0066] Figure 3 This is a flowchart that is part of a method according to one aspect of this disclosure. Figure 3 In the example, the removable metadata of the data packet in the metadata section includes an indication of the expiration time, and the method (more specifically, verifying the data packet in step 1003) includes: in step 1003a, verifying at the third device whether the expiration time has passed. Furthermore, to verify the expiration time in step 1003a, the method includes: providing the current first device time to the third device in step 1011, because in the illustrated embodiment, verifying whether the expiration time has passed in step 1003 includes: comparing the expiration time with the current first device time. Furthermore, Figure 3 The method includes: in step 1009, if the expiration time has passed, discarding the data packet; or in step 1004, if the expiration time has not passed, modifying the data packet. In step 1009, by discarding expired, invalid, or non-authentic data packets, unnecessary traffic from the third device to the second device is eliminated or minimized, thereby optimizing the use of bandwidth and power resources of the second device.

[0067] Figure 4 This is a flowchart as part of an alternative method according to one aspect of this disclosure. Figure 4 In the example, removable metadata for the data packet includes a network access code and verifiable timing information, which includes a timestamp or sequence number. Similarly, in... Figure 4 In the example, in step 1003, the verification data packet includes: authenticating the network access code, and in step 1003b, verifying verifiable timing information. Furthermore, Figure 4 The method includes: in step 1012, providing a first device time (e.g., the aforementioned current first device time) to a third device, and further includes: in step 1013, pre-sharing or negotiating the sequence number of the aforementioned data packet between the third device and the first device. Furthermore, Figure 4 The method includes: in step 1009, if the data packet is deemed invalid, discarding the data packet; and in step 1004, if the data packet is deemed valid, modifying the data packet.

[0068] Figures 5A to 5D The diagram schematically illustrates different examples of data grouping used in a method according to one aspect of this disclosure. Figure 5A In the example, data packet 20 includes a header 201, an encrypted data portion 203, and removable metadata 202, which includes an expiration time and a network access code. The header 201 is in plaintext. The network access code can be a Message Authentication Code (MAC). The MAC can also be in plaintext.

[0069] In some implementations, the data packet includes at least one of optional timing information, a timestamp, a sequence number, or an indication of an expiration time. At least one of the network access code, optional timing information, timestamp, sequence number, or indication of an expiration time is in plaintext form.

[0070] exist Figure 5B In the example, data packet 30 includes a header 301a that can be considered metadata, some other metadata 301b, an encrypted data portion 303, and a network access code 302. Figure 5B In the example, portions 301a and 301b of the data packet are in plaintext. Furthermore, the network access code 302 is removable, and the data packet portion, including header 301a, other metadata 301b, and the encrypted data portion, is compatible with the OSCORE protocol.

[0071] exist Figure 5C In the example, data packet 40a includes a header 401a, other metadata 401b, a timestamp 403a, a network access code 403b, and an encrypted data portion 402. In the context of... Figure 5C After data packet 40a was modified, by removing timestamp 403a and network access code 403b, the remaining data was... Figure 5D The data packet 40b shown includes a header 401a, other metadata 401b, and encrypted data portion 402. Figure 5D The modified data packet 40b is compatible with the OSCORE protocol.

[0072] Figure 6A The schematic diagram shows a gateway 3a as an example of a third device according to one aspect of this disclosure. Figure 6A The gateway 3a is further shown to include:

[0073] - Receiver 4, configured to receive data packets from a first device, the data packets including an encrypted data portion and a metadata portion, the metadata portion including removable metadata including a network access code that can be authenticated by means of a network access key;

[0074] - Verifier 6, which is connected to receiver 4, includes: memory 7 for storing network access keys and instructions; and processor 9, which is configured to execute instructions to cause the verifier to verify the received data packet by authenticating the network access code using the network access key, and to modify the data packet by deleting removable metadata from the data packet after verification.

[0075] - Transmitter 5, which is connected to verifier 6 to receive modified data packets from verifier 6, and is configured to send the modified data packets to a second device.

[0076] Figure 6B The schematic diagram shows another gateway 3a as another example of a third device according to one aspect of this disclosure, and Figure 6B Another gateway 3a is shown to be similar to Figure 6A The main difference in the gateway 3a shown is that, in another gateway 3a, the receiver 4 and transmitter 5 have been replaced by a single transceiver 8, which functions as both a transmitter and a receiver.

[0077] Although specific terms have been used in the foregoing description for clarity, these terms have been presented for the purposes of illustration and description of this disclosure. It is not intended to be exhaustive or to limit this disclosure to the precise forms described, and many modifications and variations are possible in accordance with the teachings above. Embodiments have been chosen and described in order to best explain the principles of the invention and its practical application. This description will enable others skilled in the art to best utilize and practice the invention in various embodiments and with various modifications suitable for a particular purpose.

Claims

1. A method for secure communication over a network, the method comprising the following steps: The device receives a data packet, the data packet comprising an encrypted data portion and a metadata portion, the metadata portion comprising a plaintext portion and removable metadata, the removable metadata including a network access code that can be authenticated by means of a network access key; Verifying the data packet, wherein the step of verifying the data packet includes authenticating the network access code using the network access key; After verifying the data group, the removable metadata is removed from the data group, thereby modifying the data group; and The modified data packets are sent to the second device. in: The first device is a cloud server; The second device is a constrained node; The removable metadata includes an indication of the expiration time; and The steps for verifying the data packets also include the following: Verify whether the expiration time has passed; and If the expiration time has expired, or authentication of the network access code fails, or both the expiration time and authentication of the network access code have failed, then the data packet is discarded. The step of verifying whether the expiration time has passed includes: comparing the expiration time with the current time of the first device.

2. The method according to claim 1, wherein, The removable metadata includes verifiable timing information, which includes timestamps or sequence numbers.

3. The method according to claim 2, further comprising the following steps: Receive from or negotiate with the first device at least one of the following: A rule or recursive relation, wherein the rule or recursive relation defines a sequence including the sequence number; The first sequence number of the sequence; or The initial term of the recursive relation.

4. The method according to claim 2, wherein, The steps for verifying the data packets also include: Verify the verifiable timing information to determine whether the data packet is valid; and If the data packet is determined to be invalid, the data packet is discarded.

5. The method according to claim 4, wherein: When the verifiable timing information includes the timestamp, the step of verifying the verifiable timing information includes comparing the timestamp with the first device time. or When the verifiable timing information includes the sequence number, the step of verifying the verifiable timing information includes comparing the sequence number with the expected sequence number.

6. The method according to claim 1, further comprising the following step: Queuing multiple data groups.

7. The method according to claim 1, further comprising the following steps: The network access key is received from the first device, wherein the network access key is derived from a trusted source.

8. The method according to claim 7, wherein, The steps for receiving the network access key include: Negotiate the network access key with the first device.

9. The method according to claim 7, wherein, The source of trust is a hardware root of trust.

10. The method according to claim 1, wherein, The removable metadata is in plaintext or includes a portion in plaintext.

11. The method according to claim 1, wherein: The data packets include at least one of optional timing information, timestamps, sequence numbers, or indications of expiration times; and At least one of the network access code, the optional timing information, the timestamp, the sequence number, or the indication of the expiration time is in plaintext form.

12. A third device for secure communication over a network, the third device comprising: A receiver configured to receive data packets from a first device, the data packets including an encrypted data portion and a metadata portion, the metadata portion including a plaintext portion and removable metadata, the removable metadata including a network access code that can be authenticated by means of a network access key; A verifier, coupled to the receiver, includes: A memory, wherein the memory stores the network access key and instructions; and A processor configured to execute the instructions to cause the verifier to verify the received data packets in the following manner: The network access key is used to authenticate the network access code; and Remove the removable metadata from the data group to change the data group; and A transmitter, connected to the verifier, and configured to receive modified data packets and transmit the modified data packets to a second device. in: The first device is a cloud server; The second device is a constrained node; The removable metadata includes an indication of the expiration time; and The steps for verifying the data packets also include the following: Verify whether the expiration time has passed; and If the expiration time has expired, or authentication of the network access code fails, or both the expiration time and authentication of the network access code have failed, then the data packet is discarded. The step of verifying whether the expiration time has passed includes: comparing the expiration time with the current time of the first device.

13. The third device according to claim 12, wherein, The processor is also configured to execute the instructions to cause the third device to negotiate the network access key with the first device.

14. A system for secure communication over a network, the system comprising: A second device, configured to receive modified data packets from a third device; as well as The third device includes: A receiver configured to receive data packets from a first device, the data packets including an encrypted data portion and a metadata portion, the metadata portion including a plaintext portion and removable metadata, the removable metadata including a network access code that can be authenticated by means of a network access key; A verifier, coupled to the receiver, includes: A memory, wherein the memory stores the network access key and instructions; and A processor configured to execute the instructions to cause the verifier to verify the received data packets in the following manner: The network access key is used to authenticate the network access code; and Remove the removable metadata from the data group to change the data group; and A transmitter, connected to the verifier, and configured to receive modified data packets and transmit the modified data packets to the second device. in: The first device is a cloud server; The second device is a constrained node; The removable metadata includes an indication of the expiration time; and The steps for verifying the data packets also include the following: Verify whether the expiration time has passed; and If the expiration time has expired, or authentication of the network access code fails, or both the expiration time and authentication of the network access code have failed, then the data packet is discarded. The step of verifying whether the expiration time has passed includes: comparing the expiration time with the current time of the first device.

15. The system according to claim 14, wherein: The third device is a gateway.

16. The system according to claim 14, wherein, The third device is configured as a proxy to the second device.

17. The system according to claim 14, wherein, The removable metadata includes verifiable timing information, which includes timestamps or sequence numbers.

Images