Granted Patent B2

US 12,665,877 · App. 18/196,689 · Granted Jun 23, 2026

Inventors: Adam Vandenbussche (Kirkland, CA); David Kotz (Lyme, NH); Timothy Pierson (Hanover, NH)

Assignee: THE TRUSTEES OF DARTMOUTH COLLEGE

H04L63/0236H04L45/745H04L63/0435

Abstract

Claims (101)

1 . A computer-implemented method of providing user data privacy for smart devices connected to a smart home router participating as a node in one or more circuits of an onion routing network of routers connected to a network, the method comprising:

receiving a plaintext Internet Protocol (IP) packet from a smart device at an originator node smart home router; and

checking a packet destination which comprises a domain name or a destination IP address against a locally stored allowlist of cloud-based destinations associated with smart devices to verify that the packet destination is included in the allowlist, wherein the allowlist comprises domain names or IP addresses received from a central authority and periodically updated; and

when the packet destination is included in the allowlist:

identifying a preformed circuit of at least a guard, a middle, and an exit node in the onion routing network;

encapsulating the plaintext IP packet in at least a first, a second and a third layer of encryption, each layer including a first, second, or third cleartext destination of the guard, middle, or exit smart home router, and a first, second or third encrypted payload, respectively; and

sending the encapsulated packet to the guard node at the first cleartext destination; and

wherein the exit node in the onion routing circuit verifies that a destination IP address of a non-DNS packet matches an IP address previously returned by that exit node in response to resolving an allowlist domain name, and refuses to forward the packet if the destination IP address does not match;

when the packet destination is not included in the allowlist:

sending the plaintext IP packet to the cloud-based destination.

2 . The method of claim 1 , wherein when the plaintext IP packet contains a domain name server (DNS) request payload containing a domain name,

checking the packet destination further comprises:

checking the domain name against a allowlist of cloud-based domains to verify that the domain name is included in the allowlist.

3 . The method of claim 2 , wherein the allowlist is maintained by one or more central authorities.

4 . The method of claim 3 , wherein a smart device user may consent to having a list of domain names contacted by some of the smart devices in a home of the smart device user anonymously shared with the one or more central authorities.

5 . The method of claim 1 , wherein when the IP packet is a non-DNS payload and the packet destination is a destination IP address, checking the packet destination further comprises:

checking the destination IP address against a locally cached set of IP addresses known to be associated with allowlisted domain names.

6 . The method of claim 1 , further comprising the smart home router serving as a guard node by:

receiving the encapsulated packet;

decrypting the first layer of encryption to determine the second cleartext destination and the second encrypted payload; and

sending the second encrypted payload to the second cleartext destination.

7 . The method of claim 6 , further comprising the smart home router serving as a middle node by:

receiving second encrypted payload;

decrypting the second encrypted payload to determine the third cleartext destination and the third encrypted payload; and

sending the third encrypted payload to the third cleartext destination.

8 . The method of claim 7 , further comprising the smart home router serving as an exit node by:

receiving the third encrypted payload;

decrypting the third encrypted payload to reveal the plaintext IP packet;

checking the packet destination against the allowlist of smart device domains; and

when the packet destination is in the allowlist, sending the plaintext IP packet to the packet destination;

when the packet destination is not in the allowlist, ignoring the plaintext IP packet.

9 . The method of claim 8 , wherein the plaintext IP packet is a domain name server (DNS) request payload containing a domain name, and the method further comprises:

checking the domain name against an allowlist of cloud-based destinations to verify that the domain name is included in the allowlist;

when the domain name is included in the allowlist:

placing a DNS request for the domain name to a DNS server;

receiving and saving a set of IP addresses associated with the domain name from the DNS server;

encapsulating the set of IP addresses as plaintext IP packet in at least the third, second and first layers of encryption, each layer including the third, second or first cleartext destination of the third, second or first smart home router; and

forwarding the encapsulated set of IP addresses to the third cleartext destination; and

when the domain name is not included in the allowlist, ignoring the DNS request.

10 . The method of claim 1 , wherein the plaintext IP packet is a DNS request containing a domain name that was resolved by an exit router, and the method further comprises:

receiving a set of IP addresses associated with the domain name;

temporarily storing the set of IP addresses in a local IP cache;

when the IP address already appears in the local IP cache:

when the domain name in the DNS request is the same as the domain name that is associated with the locally cached IP address:

resetting a time-to-live (TTL) of the IP address;

when the domain name in the DNS request is different than the domain name that is associated with the locally cached IP address:

adding that domain name to a list of domain names associated with that locally cached IP address;

when the IP address does not already appear in the local IP cache:

adding the IP address to the local cache with a configured TTL;

adding that domain name to the list of domain names associated with that locally cached IP address.

11 . The method of claim 1 , further comprising the router periodically removing IP addresses from its local cache when their TTL has expired.

12 . An onion routing network comprising a plurality of circuits of nodes for protecting privacy of data packets generated by smart devices, each circuit comprising an originator node, a guard node, at least one middle node, and an exit node, comprising:

a first node designated as an originator node for:

receiving the data packets from a smart device, comparing a packet destination which comprises a domain name or a destination IP address against a locally stored allowlist of cloud-based destinations associated with smart devices, and if when the domain name is in the allowlist, encapsulating the data packet with a plurality of layers of encryption and forwarding the data packets packet to the onion routing network; or

when the packet destination is not included in the allowlist, sending the data packet to the cloud-based destination; or

receiving the data packets from the onion routing network and sending them to the smart device;

a second node designated as a guard node for:

receiving the data packets from the originator node and forwarding them to at least one middle node; or

receiving the data packets from the at least one middle node and forwarding them to the originator node;

a third node designated as a middle node for:

receiving the data packets from the guard node and forwarding them to the exit node; or

receiving the data packets from the exit node and forwarding them to the guard node; and

a fourth node designated as an exit node for:

receiving the data packets from the middle node and sending the data packets to a cloud-based destination; or

receiving packets from the cloud-based destination and sending them to the middle node;

wherein the exit node verifies that a destination IP address of a non-DNS packet matches an IP address previously returned by that exit node in response to resolving an allowlist domain name, and refuses to forward the packet if the destination IP address does not match.

13 . The network of claim 12 , the first node comprising:

a first processor and a first non-transitory memory storing instructions that are executed by the first processor to:

compare the domain name in DNS packets with the allowlist of domain names;

when the domain name is not in the allowlist, route the data packet to the cloud-based destination;

compare IP address destinations of non-DNS packets with local set of cached IP addresses;

when the IP address is in the local set of cached IP addresses, encapsulate the data packet with a plurality of layers of encryption and route the encapsulated data packet to the guard node; and

when the IP address is not in the local set of cached IP addresses, route the data packet to the cloud-based destination.

14 . The network of claim 12 , the second node comprising:

a second processor and a second non-transitory memory storing instructions that are executed by the second processor to:

receive an encapsulated data packet from the first node or the third node;

remove a layer of encryption from the encapsulated data packet; and

forward the encapsulated data packet to the third node or the first node, respectively.

15 . The network of claim 12 , the third node comprising:

a third processor and a third non-transitory memory storing instructions that are executed by the third processor to:

receive an encapsulated data packet from the second node or the fourth node;

remove a layer of encryption from the encapsulated data packet; and

forward the encapsulated data packet to the second node or the fourth node, respectively.

16 . The network of claim 12 , the fourth node comprising:

a fourth processor and a fourth non-transitory memory storing instructions that are executed by the fourth processor to:

receive an encapsulated data packet from the third node;

decrypt the encapsulated data packet;

when the encapsulated data packet is a DNS request containing a domain name:

compare the domain name in the DNS request with an allowlist;

when the domain name is in the allowlist, route the data packet to the cloud-based destination; or

when the encapsulated data packet does not contain a DNS request:

compare an IP address destination of the encapsulated data packet with a local set of cached IP addresses; and

when the IP address is in the local set of cached IP addresses, route the data packet to the cloud-based destination.

17 . The network of claim 16 , the fourth non-transitory memory storing further instructions that are executed by the fourth processor to:

receive a data packet from the cloud-based destination;

encapsulate the data packet with a plurality of layers of encryption; and

forward the encapsulated data packet to the third node.

18 . The network of claim 16 , wherein the encapsulated data packet from a smart device includes a DNS request and the cloud-based destination is a DNS server, the fourth non-transitory memory storing instructions that are executed by the fourth processor to:

receive a set of IP addresses associated with the domain name from the DNS server;

save the set of IP addresses in the fourth non-transitory memory; and

forward the set of IP addresses to the first node.

Assignments (1)

Continuity (2)

References Cited (29)