US20190044796A1 - Dead drop network architecture - Google Patents
Dead drop network architecture Download PDFInfo
- Publication number
- US20190044796A1 US20190044796A1 US16/152,362 US201816152362A US2019044796A1 US 20190044796 A1 US20190044796 A1 US 20190044796A1 US 201816152362 A US201816152362 A US 201816152362A US 2019044796 A1 US2019044796 A1 US 2019044796A1
- Authority
- US
- United States
- Prior art keywords
- node
- dead drop
- specified
- recipient
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0681—Configuration of triggering conditions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0876—Network utilisation, e.g. volume of load or congestion level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/104—Grouping of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/126—Applying verification of the received information the source of the received data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H04L51/12—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/212—Monitoring or handling of messages using filtering or selective blocking
Abstract
A dead drop at a node in a dead drop (DD) domain performs actions responsive to detecting events in the DD domain. The node receives a notification request specifying an event to be monitored, the notification request including a dead drop identifier (DDID) referencing a storage location in the DD domain associated with the specified event and a token associated with the DDID. The node further specifies the action to perform in response to detecting the occurrence of the specified event. The node monitors for an occurrence of a specified event within the DD domain. The node detects the occurrence of the specified event within the DD domain. The node further performs a specified action in response to detecting the occurrence of the specified event within the DD domain.
Description
- This application is a continuation of U.S. application Ser. No. 15/640,211, filed on Jun. 30, 2017, which is a continuation of U.S. application Ser. No. 15/136,347, filed on Apr. 22, 2016, issued as U.S. Pat. No. 9,729,390, which claims the benefit of U.S. Provisional Application No. 62/151,188, filed Apr. 22, 2015, U.S. Provisional Application No. 62/193,927, filed Jul. 17, 2015, U.S. Provisional Application No. 62/193,930, filed Jul. 17, 2015, and U.S. Provisional Application No. 62/214,124, filed Sep. 3, 2015, all of which are incorporated by reference herein.
- The present invention generally relates to the field of computer networking and data storage and in particular to a network architecture for facilitating secure data exchange over a decentralized computer network and data storage architecture.
- The Internet (including the Web) enables users of computers to quickly and easily exchange data. There is a wide range of applications that leverage this ability to exchange data to achieve powerful results for individuals and enterprises alike. Examples include email, file sharing, home automation, entertainment, data management, and more.
- However, the way that data is exchanged over the Internet makes the data, and those who send the data, vulnerable to malicious actors. For instance, data moving between parties or stored on a remote server typically include information associated with the sender and the recipient. Accordingly, an interceptor of the data may associate the data with the parties. If the data contain sensitive information, it may leave the parties open to identity theft or other malicious acts. As a result, many users are discouraged from sharing important information via the Internet, thereby missing out on many of the advantages that are afforded to computer users.
- According to embodiments of the invention, a method for performing an action responsive to detecting an event in a dead drop (DD) domain is described. The method includes monitoring, by a node in the DD domain, for an occurrence of a specified event within the DD domain. The method further includes detecting the occurrence of the specified event within the DD domain. The method further includes performing a specified action in response to detecting the occurrence of the specified event within the DD domain.
- According to embodiments of the invention, a system for exchanging data between a sender and a recipient is described. The system includes a processor for executing computer program instructions. The system also includes a non-transitory computer-readable storage medium storing computer program instructions executable by the processor to perform steps. The steps include monitoring, by a node in the DD domain, for an occurrence of a specified event within the DD domain. The steps further include detecting the occurrence of the specified event within the DD domain. The steps further include performing a specified action in response to detecting the occurrence of the specified event within the DD domain.
- According to embodiments of the invention, a non-transitory computer-readable storage medium storing computer program instructions for exchanging data between a sender and a recipient. The computer program instructions are executable to perform steps. The steps include monitoring, by a node in the DD domain, for an occurrence of a specified event within the DD domain. The steps further include detecting the occurrence of the specified event within the DD domain. The steps further include performing a specified action in response to detecting the occurrence of the specified event within the DD domain.
-
FIG. 1 is a high-level block diagram illustrating an example of passing data using a dead drop network architecture according to one embodiment. -
FIG. 2 is a high-level block diagram illustrating a detailed view of the dead drop domain ofFIG. 1 according to one embodiment. -
FIG. 3 is a high-level block diagram illustrating an example of a dead drop storage node according to one embodiment. -
FIG. 4 is a flowchart illustrating steps for using a dead drop to pass data from a sender to a recipient according to one embodiment. -
FIG. 5 is a flowchart illustrating steps for using a DD to monitor events and perform actions if an event is detected according to one embodiment. -
FIG. 6 is a high-level block diagram illustrating an example of two nodes establishing a direct connection according to one embodiment. -
FIG. 7 is a high-level block diagram illustrating physical components of a computer used as part or all of one or more of the entities described herein in one embodiment. - The Figures (FIGS.) and the following description describe certain embodiments by way 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 described herein. Reference will now be made to several embodiments, 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. This description occasionally uses reference numbers in combination with letters to designate items illustrated in the figures. Herein, a reference number used without an accompanying letter (e.g., “150”) references any or all instances of the designated item, while a reference number used with an accompanying letter (e.g., “150A”) refers to the specific item designated with that label in the figure.
-
FIG. 1 is a high-level block diagram illustrating an example of passing data using a dead drop network architecture according to one embodiment.FIG. 1 illustrates arecipient 110 in communication with asender 120 via a dead drop (DD)domain 130.FIG. 1 describes a unidirectional data pass between asingle sender 120 and asingle recipient 110. Embodiments can havemultiple senders 120 andrecipients 110 engaged in bidirectional one-to-one and one-to-many communications. - Briefly, the
recipient 110 uses theDD domain 130 to establish a communication channel that can be used to pass data to the recipient. Therecipient 110 provides thesender 120 with a dead drop identifier (DDID) referencing a storage location within the DD domain. Thesender 120, in turn, uses the DDID to pass data (e.g., send a message) to therecipient 110 via theDD domain 130. The data transmission from thesender 120 to therecipient 110 is secure in the sense that it is extremely difficult for a malicious actor or other third party to locate, intercept, or decipher the data. Thus, the DD network architecture is suited to communications where security and privacy concerns are paramount. In addition, the DD network architecture may be used to provide enhanced security for general purpose communications. - In one embodiment, the
recipient 110 includes software executing on a computer used by a user (e.g., a person) to perform tasks such as communicating with other users via theDD domain 130 or via other communication networks. For example, therecipient 110 may include software executing on a desktop, notebook, or tablet computer, or another electronic device with computer functionality, such as a mobile telephone, music player, television set-top-box, home automation component, industrial equipment or connected appliance. Therecipient 110 may include an input device such as a keyboard or touch-sensitive display that allows for the input of data and an output device such as a display or speaker that allows for the output of data. Functionality enabling therecipient 110 to communicate via theDD domain 130 may be embedded into the hardware of therecipient 110 and/or included in software executed by therecipient 110. - Similarly, the
sender 120 includes a computer used by a user to perform tasks including communicating with other users via theDD domain 130 or via other communication networks. Thesender 120 may include the same components as therecipient 110. In fact, thesender 120 may act as arecipient 110 and vice versa, depending upon the direction of data flow in a given communication transaction. The users who respectively use therecipient 110 andsender 120 to communicate can be different people or the same person. - The
recipient 110 andsender 120 are connected to theDD domain 130 viarespective communications links - The
DD domain 130 is a collection of one or more DD nodes 140 (labeled asnodes 140A-L inFIG. 1 ).ADD node 140 includes functionality for acting in theDD domain 130 and a memory for storing data within the domain. Atypical DD domain 130 includesmany DD nodes 140. Eachnode 140 is connected to one or more other nodes via DD communication links 160. The DD communication links 160 may use the same communication technologies as the communication links 150 used by therecipient 110 andsender 120 to connect to theDD domain 130. In one embodiment, theDD nodes 140 and DD communication links 160 are arranged within theDD domain 130 such that every node is reachable by every other node. In another embodiment, theDD nodes 140 are logically or physically partitioned so that some nodes cannot reach other nodes. The path connecting twoDD nodes 140 may pass through one or more intermediate nodes. In addition, therecipient 150A andsender 150B communication links respectively connect therecipient 110 and thesender 120 to at least oneDD node 140 within theDD domain 130. Therecipient 110 andsender 120 may also communicate with each other using other communication links that do not pass through theDD domain 130, such as acommunications link 170. - To receive data using the
DD domain 130, therecipient 110 sends a request to theDD domain 130 to create a DD on behalf of the recipient.ADD node 140 within thedomain 130 receives the create request and either services the request or selects another node to service the request. For example, theDD node 140 that receives the request may randomly select another node within theDD domain 130 and pass the request to the selected node. The random selection may occur in a manner such that the node that receives the request does not know which node ultimately services the request. - The
node 140 that services the request to create the DD establishes a DDID that uniquely identifies the created DD. In addition, thenode 140 establishes a set of tokens associated with the DDID. A token describes the access rights a possessor of the token has with respect to the created DD. For example, an embodiment includes a read token giving a possessor of the token the right to read from the DD identified by the associated DDID and a write token giving the right to write to the DD identified by the associated DDID. Thenode 140 that services the request provides the DDID and the associated tokens to therecipient 110. - The
recipient 110 typically stores the DDID and associated tokens in a secure manner. For example, therecipient 110 may store the DDID and tokens in an encrypted data store at the recipient. Therecipient 110 provides the DDID and the write token to thesender 120 via acommunications link 170. This communications link 170 may be a secure or unsecure link, and may include communication over the Internet and/or dedicated communications links. For example, therecipient 110 may use encrypted or unencrypted email to send the DDID and write token to thesender 120. Alternatively, the recipient may use a different electronic communications technique, such as short-range wireless communications, or even use non-electronic techniques to exchange the information (e.g., a pen and paper). In one embodiment, the DDID and one or more tokens are combined and may be encrypted or encoded (e.g., by a hashing function) to form a single code. In this embodiment, therecipient 110 may share the code with thesender 120 instead of sharing the DDID and write token separately. The code may be decoded, for example by thesender 120 or at aDD node 140, to determine the DDID and token. - In addition, the
recipient 110 andsender 120 may choose to encrypt the data sent by the sender using one or more symmetric or asymmetric encryption techniques. Therecipient 110 andsender 120 may choose to exchange encryption keys, if necessary, at the same time therecipient 110 provides the DDID and write token to thesender 120. Alternatively, therecipient 110 andsender 120 may exchange encryption keys at different times, may use encryption techniques that do not require a key exchange, or may choose not to encrypt the data. In one embodiment, theDD domain 130 itself is used to perform the key exchange needed to facilitate an encrypted communications link. - The
sender 120 uses the DDID and associated write token to send data to therecipient 110. In one embodiment, thesender 120 sends a write request to theDD domain 130 that includes the DDID and the write token. In another embodiment, the write request includes the DDID and data representing the write token. The data representing the write token may be encrypted (e.g., by hashing, obfuscation, etc.). This request is received by aninitial DD node 140 in theDD domain 130. The receivingnode 140 determines whether it has the DD identified by the DDID. If not, the receivingnode 140 sends a message containing the DDID and the write token to the other nodes withinDD domain 130. Thenode 140 storing the DD associated with the DDID receives the message and verifies the write token. If the token verifies, the node storing the DD creates a connection with the receiving node, which in turn has a connection with thesender 120. Thesender 120 then writes the data to the node storing the DD associated with the DDID. - Similarly, the
recipient 110 uses the DDID and associated read token to read data from the DD. In one embodiment, therecipient 110 sends a read request to theDD domain 130 that includes the DDID and the read token. In another embodiment, the read request includes the DDID and data representing the read token. The data representing the read token may be encrypted (e.g., by hashing, obfuscation, etc.). This request is received by aninitial DD node 140 in theDD domain 130. The receivingnode 140 determines whether it has the DD identified by the DDID. If not, the receivingnode 140 broadcasts a message containing the DDID and the read token the other nodes within theDD domain 130. Thenode 140 storing the DD associated with the DDID receives the message and verifies the read token. If the token verifies, thenode 140 storing the DD creates a connection with the receiving node, which in turn has a connection with the recipient. Therecipient 110 then reads the data from the node storing the DD associated with the DDID. - Thus, the DD network architecture described above permits secure and private communications between the
recipient 110 and thesender 120. Thesender 120, and/or other parties possessing the DDID and write token can send data to the recipient. However, such parties cannot read the data from the DD. Moreover, a malicious actor who obtains access to one ormore nodes 140 in theDD domain 130 may be able to obtain or read data stored in individual DDs. But the malicious actor cannot determine the intended recipients of the data because there is no mapping of DDIDs to recipients. For the same reason, the malicious actor cannot determine the path between a sender and a recipient. In addition, the data stored in the DDs may be encrypted. -
FIG. 2 is a high-level block diagram illustrating a detailed view of theDD domain 130 ofFIG. 1 according to one embodiment. As described above, thedomain 130 typically includesmultiple DD nodes 140 connected by DD communication links 160. Theindividual nodes 140 within theDD domain 130 may be formed of physically separate computers, such as a collection of geographically disparate computers. In addition, some or all of the nodes may be formed of virtual computers. For example, thenodes 140 of adomain 130 may be instances of virtual computers hosted in a cloud environment. - Each
DD node 140 has an associated set of characteristics that describe attributes of the node. The characteristics may describe the location of thenode 140. The location may be specified as a geographic location. In addition, the location may be specified as a logical location (e.g., a “zone”). For example, the logical location may indicate that the node is associated with a particular enterprise (e.g., a business) or other group. The characteristics may also describe physical properties of the node, such as a node's processing power, storage capacity, uptime, and the like. - In one embodiment, the set of
DD nodes 140 in aDD domain 130 may be divided into multiple subdomains, with each subdomain including a proper subset of nodes from the set of DD nodes in the DD domain. The subdomains to which anode 140 is member may be determined based on the characteristics of the node. For example, theDD domain 130 may includenodes 140 distributed over a wide geographic area (e.g., a country), and a subdomain may include nodes physically located within a smaller area (e.g., a state within the country). Similarly, theDD domain 130 may includenodes 140 associated with multiple enterprises, and a subdomain may include only nodes associated with one of the enterprises or a part of an enterprise. - In one embodiment, the
DD nodes 140 are arranged as a mesh network. Eachnode 140 is connected to at least one other node via aDD communication link 160. Moreover, eachnode 140 maintains a routing table identifying the nodes to which it is connected. Anode 140 can send a message to another node by forwarding the message to the nodes to which it is connected. Thenodes 140 that receive the message in turn forward the message to other nodes, until the message reaches the node to which it is directed. The path followed by the message is formed of hops fromnode 140 to node along the DD communication links 160. - Consider the communications between the
sender 120 and therecipient 110 described inFIG. 1 in the context ofFIG. 2 . As shown inFIG. 2 , therecipient 110 is connected to anode 140A of thedomain 130 via acommunication link 150A. Thisnode 140A serves as the point of ingress to thedomain 130 for the recipient. Therecipient 110 sends a request to theingress node 140A of thedomain 130 to create a DD on behalf of the recipient. This request may include domain information specifying a particular subdomain in which the DD should be created. For example, the domain information may specify that the DD should be created in anode 140 located in a particular geographic area or managed by a particular enterprise. - The
node 140A serving as the point of ingress for therecipient 110 receives the create request and analyzes the domain information to identify the subdomain in which the DD should be created. In one embodiment, thenode 140A services the request by randomly selecting a node within the specified subdomain that will host the DD. In one embodiment, random selection is performed using a load balancing technique, which may be performed by thenode 140A or by a separate computing device. In one embodiment, thenode 140 services the request by randomly selecting a number of node hops for which the request will be forwarded, and randomly selecting another node within the specified subdomain to which thenode 140A is connected. Theingress node 140A then forwards the request to the randomly selected node (e.g.,node 140D) and also forwards the selected value for the number of node hops. Thenode 140D to which the request was forwarded randomly selects another node (e.g.,node 140E) in the subdomain from its routing table, decrements the value for the number of node hops, and forwards the request to the selected node. This selection, decrement, and forward process repeats until the value for the number of node hops reaches zero, at which point the final node establishes and hosts the DD associated with the request from therecipient 110. In one embodiment, each node that forwards the create request includes the path from theingress node 150A to the forwarding node with the request. The final node that creates the DD uses the path to identify and contact theingress node 140A for therecipient 110. For example, thenode 140 may use the path to send the DDID and associated tokens to theingress node 140A, so that the latter node can provide this information to the recipient. - For example, assume the
ingress node 140A receives a create request from therecipient 110, and also assume that the request specifies asubdomain encompassing nodes domain 130. Also assume theingress node 140A randomly selects “2” as the number of hops. The ingress node randomly selects a node (e.g.,node 140D) from the specified subdomain in its routing table, decrements the hop value, and forwards the request and decremented hop value (e.g., “1”) to the selected node. Thatnode 140D, in turn, randomly selects another node (e.g.,node 140E), decrements the hop value, and forwards the request and decremented hop value (e.g., “0”) to the selected node. Thefinal node 140E evaluates the hop value and determines that it is “0” and, therefore, creates the DD and associated tokens. Thefinal node 140E then returns the DDID and tokens to theingress node 140A via the reverse of the path used to reach the final node. - Variations on the techniques described above may be used in some embodiments. In one embodiment, a node forwarding a request decrements the hop value only if the node is within the specified subdomain. This variation may be used, for example, in situations in which a node receiving a create request is not within the specified subdomain and/or connected to any other nodes in the subdomain. In this situation, the nodes may randomly forward the request to other nodes until a node within the specified subdomain receives the request, at which point the node in the subdomain decrements the hop value and forwards the request anew if the hop value is greater than zero or creates the DD and associated tokens if the hop value is zero.
- The
sender 120, in turn, is connected to adifferent node 140L that serves as the point of ingress for the sender to thedomain 130 via adifferent communication link 150B. When thesender 120 makes a write request, the sender provides the DDID and write token to the sender'singress node 140L. Thisnode 140L forwards the request including the DDID and write token to the other nodes in its routing table, and the other nodes continue to forward the request until it reaches the node having the DD associated with the DDID (e.g.,node 140E). Thisnode 140E verifies the token and establishes a connection with the sender'singress node 140L using a return path created by the forwarding nodes. Alternatively, thenode 140E may establish a direct connection with thesender 120. Thesender 120 provides the data to be written to theingress node 140L, and that node forwards the data to thenode 140E having the DD via the connection. A read request made by therecipient 110 is handled in a similar fashion in one embodiment, except that the recipient reads data from, rather than writes data to, thenode 140E having the DD. -
FIG. 3 is a high-level block diagram illustrating an example of aDD node 140 according to one embodiment. Thenode 140 includes arouting module 305,creation module 310,write module 315, readmodule 320, time-to-live (TTL)module 325,data control module 330, deletemodule 335,notification module 340, geo-fence module 345, anddata storage 390. Other embodiments may include different or other modules in other embodiments. In addition, the behaviors of the modules may differ in other embodiments. - The
data storage 390 stores data used by thenode 140. The data may include data being maintained in DDs managed by thenode 140, DDIDs and tokens associated with the DDs, and information used by the modules within thenode 140 to perform the tasks described herein. Depending upon the embodiment, thedata storage 390 may include one or more types of non-transitory computer-readable persistent storage media. For example, thedata storage 390 may include a hard drive, solid-state memory device, and/or other form of persistent memory. - Turning now to the individual modules within the
node 140, therouting module 305 routes messages received bynode 140. As part of this task, an embodiment of therouting module 305 maintains the routing table for thenode 140. Therouting module 305 periodically communicates withother nodes 140 to which it is connected to ascertain information about those nodes. This information may include, for example, network addresses of the nodes, information about the subdomains with which thenodes 140 are associated, and the like. Therouting module 305 stores this information about the connected nodes in the routing table. In addition, therouting module 305 responds to routing table-related communications from routingmodules 305 ofother nodes 140. - The messages handled by the
routing module 305 include messages related to create requests, write requests, read requests, and other types of messages and requests described herein. For a given message, therouting module 305 analyzes the message to determine whether to process the message locally on thenode 140 or to route the message to another node in the routing table. For example, upon receiving a create request from another node, therouting module 305 examines the hop value to determine whether it is greater than zero. If the hop value is greater than zero, therouting module 305 decrements the hop value, randomly selects a connected node in the routing table (subject to any specified subdomain constraints, if applicable), and forwards the request and decremented hop value to the selected node. If the hop value is zero, therouting module 305 provides the request to thecreation module 310. - Similarly, upon receiving a write request, the
routing module 305 determines whether the DDID is associated with a DD maintained by thenode 140. If the DDID is not associated with a DD maintained by thenode 140, therouting module 305 forwards the request to other nodes in its routing table. If, on the other hand, the DDID is associated with a DD maintained by the node, therouting module 305 provides the request to thewrite module 315. Therouting module 305 handles read requests, as well as other requests described herein, in the same fashion. - The
creation module 310 creates DDs in response to requests received by thenode 140. Upon receiving a create request from therouting module 305, thecreation module 310 generates a DDID to represent the DD for the request. In addition, thecreation module 310 generates a set of tokens associated with the DDID. Thecreation module 310 provides the DDID and tokens to therecipient 110 that requested the DD using the path to the recipient'singress node 140A as described with respect toFIGS. 1 and 2 . - In one embodiment, the
creation module 310 generates the DDID as a globally unique identifier (GUID). The DDID is a value represented using a large number of bits (e.g., a 128-bit value). A small portion of the bits may be fixed to identify the value as a DDID or encode other information, while the other bits are randomly generated by thecreation module 310. The large number of bits makes it extremely unlikely that the same DDID would be generated for multiple DDs. Therefore, each DDID is unique for practical purposes. The DDID may be represented as sequence of hexadecimal digits. - In one embodiment, the tokens generated by the
creation module 310 may include a write token, a read token, and an owner token. The write and read tokens respectively provide the bearer of the token the rights to write data to, and read data from, the DD associated with the DDID as described above. The owner token provides the bearer with administrative rights to the DD, such as the right to delete data within the DD or delete the entire DD. - In one embodiment, a token, like the DDID, is a value represented using a large number of bits, some of which may be fixed and others of which are randomly generated by the
creation module 310. The number of bits in each token may be fewer than the number of bits in the DDID. Each token associated with a particular DDID is unique with respect to other tokens associated with that DDID. - The
creation module 310 allocates space in thedata storage 390 for the created DD and associates this space with the DDID. The amount of space, and the time when the space is allocated may vary in different embodiments. In one embodiment thecreation module 310 allocates a fixed amount of storage space for the DD when creating the DD. In another embodiment, thecreation module 310 allocates the storage space later, when receiving data to store in the DD. Likewise, the amount of space allocated for the DD can vary in different embodiments. - The
write module 315 writes data to DDs in response to write requests received by thenode 140. Upon receiving a write request from therouting module 305, thewrite module 315 initially verifies the write token included in the request. Thewrite module 315 identifies the - DDID and write token included in the request, and compares the write token to the stored write token created by the
creation module 310 for the DDID. If the compared write tokens do not match, thewrite module 315 denies the write request. Depending upon the embodiment, thewrite module 315 can deny the request by acting as if the request was not received (i.e., by not sending any messages in response to the write request) or by sending a message to thesender 120 indicating that the write token is invalid. - If the compared write tokens match, the
write module 315 uses the return path in the write request to open a network connection with theingress node 140L for thesender 120. Thewrite module 315 receives data from the sender of the write request, and writes the data to the storage allocated for the DD identified by the DDID. In one embodiment, thewrite module 315 stores the data in a DD as a series of discrete messages, such that the data for each write request to a DD is saved as a logically separate message. The stored messages for the DD are organized in a queue or another data structure. - The
read module 320 reads data from DDs in response to read requests received by thenode 140. Upon receiving a read request from therouting module 305, theread module 320 initially verifies the read token included in the request. Theread module 320 identifies the DDID and read token included in the request, and compares the read token to the stored read token created by thecreation module 310 for the DDID. If the compared read tokens do not match, theread module 320 denies the read request. Like thewrite module 315, theread module 320 can deny the request by acting as if the request was not received (i.e., by not sending any messages in response to the read request) or by sending a message to therecipient 110 indicating that the read token is invalid. - If the compared read tokens match, the
read module 320 uses the return path in the read request to open a network connection with theingress node 140A for therecipient 110. Theread module 320 reads data from the storage allocated for the DD, and sends the data to therecipient 110 via theingress node 140A. In another embodiment, a direct connection is established between the node storing the DD and therecipient 110 and the data is sent to the recipient without passing through theingress node 140A. If the data in the storage is organized in a queue, an embodiment of theread module 320 sends the message in the queue in response to the request (e.g., in a first-in-first-out order) and removes the message from the queue after it is sent. Other embodiments may send multiple messages per read request and/or leave message in the queue after the messages are sent to therecipient 110. In another embodiment, the contents of a DD are not read, for example, because the holder of a read token corresponding to the DD no longer wishes to communicate with the sender of the message. In this case, communication may be disconnected unilaterally by the recipient, without action, consent, or knowledge by the sender. - The
TTL module 325 maintains TTL information for thenode 140. The TTL information generally describes for how long an entity persists in thedomain 130. For example, DDs, DDIDs, tokens, and data written to DDs may have associated TTL information that describes how long the respective entities persist within thedomain 130. Once the duration described by the TTL is reached, the entity to which the TTL pertains expires, is no longer recognized as valid, and may be deleted. - In addition, the
TTL module 325 enforces the TTLs by detecting when a duration described by a TTL is reached, and invalidating the entity associated with the TTL. For example, if theTTL module 325 detects that a TTL for a DD is reached, the TTL module deletes the data stored within the DD and also deletes or otherwise invalidates the DDID and tokens associated with the DD so that the DD can no longer be accessed. Similarly, if theTTL module 325 detects that a TTL for data written to a DD is reached, theTTL module 325 deletes the data from the DD so the data can no longer be read. - The TTL information may be specified as a counter (e.g., a duration of time from the present time) or as a timestamp (e.g., an explicit time after which the entity is no longer valid). Additionally, the TTL may be specified as a number of instances of particular types of access (e.g., a DD expires once it is read from 3 times, or written to once). Further, the TTL information may be specified as a category (e.g., “default,” “short,” “medium,” “long,” or “confidential”). In the latter case, the
TTL module 325 converts the category description to a counter or timestamp based on a TTL policy. Different entities may have different applicable TTL policies. For example, the TTL policies may specify that the “default” TTL for a DD is 30 days and the “default” TTL for a message is 7 days. TheTTL module 325 may also support an “archive” TTL that does not expire, therefore making the entity having the TTL persistent. - In one embodiment, the
recipient 110 specifies the TTL for a DD when creating it. For example, the TTL information may be embedded into the create request. Likewise, thesender 120 may specify the TTL for data by embedding the TTL in the write request. For example, therecipient 110 may specify a specific amount of time or number of instances of access for which the DD is valid, or specify a category as discussed above. The TTL specified for the DD is embedded into the create request and received by theTTL module 325. - The
data control module 330 supports management of DDs for thenodes 140 of thedomain 130. Thedata control module 330 provides a variety of management functions that can be accessed by therecipient 110 or other entity making a request for a particular function and providing tokens granting administrative authority, reading privilege, writing privilege, etc. for a given DD. - In one embodiment, the
data control module 330 provides a movement function that moves a DD from onenode 140 to another node while maintaining the same DDID. Therecipient 110 may issue a move request that contains the DDID, the owner token and, optionally, a specification of a node to which the DD should be moved. In various embodiments, movement of a DD may be initiated by a user request, environmental factors (e.g., anode 140 is scheduled to be taken offline, time of day), or a policy definition (e.g., a DD may only stay on aspecific node 140 for a certain time before it is required to be moved). Thenode 140 to which the DD should be moved may be specified, for example, by indicating a subdomain to which the DD should be moved. In response to a move request having a valid owner token, thedata control module 330 of thenode 140 having the DD identified by the DDID identifies a new node to which the DD is to be moved. For example, thedata control module 330 may randomly select a new node within the specified subdomain using the random selection technique described above and send that node a message identifying the DDID and the data for maintaining in the DD identified by the DDID. Adata control module 330 in thenew node 140 establishes a new DD under the existing DDID, and stores the received data in that DD. Once the new DD is established, thedata control module 330 may optionally delete the DD identified by the DDID so that the DD has effectively been moved to the new node. - The
data control module 330 also provides a replicate function that replicates a DD from anode 140 to one or more other nodes. The replication is similar to the movement function, except that the originaldata control module 330 does not delete the DD identified by the DDID after the new DD is created. In one embodiment, replication is initiated by arecipient 110. In another embodiment, replication is initiated automatically (e.g., by executable instructions stored in the DD that specify rules for replication). When anode 140 containing a replicated DD fulfills a write request, therouting module 305 forwards the write request to other nodes in the routing table so that each instance of the replicated DD may fulfill the write request and maintain data currency. - The
data control module 330 further provides an archive function that stores an archive of a DD in anothernode 140. To perform the archive, thedata control module 330 of thenode 140 storing the DD receives an archive request similar to the move request. Thedata control module 330 communicates with thedata control module 330 of thenew node 140 to create a new DD associated with the same DDID. Thedata control module 330 sets the TTL for the entities associated with the new DD as “persistent,” meaning that the new DD acts as an archive for the DD in the original node. Thedata control module 130 of theoriginal node 130 may optionally delete the DD identified by the DDID after the archive is created. - The
delete module 335 deletes DDs from anode 140. Thedelete module 335 receives a delete request from therecipient 110 or another entity. The delete request contains a DDID and the associated owner token. Thedelete module 335 verifies that the received token grants delete privileges and, if it does, deletes the DD identified by the DDID from thenode 140. In another embodiment, deletemodule 335 may delete one or more messages stored in a DD and not the entire DD itself. In one embodiment, thedelete module 335 writes data to the storage location from which the DD is deleted. This writeover data may be randomly generated or predetermined. Writing writeover data makes recovering deleted data more difficult. It also makes finding DD data more difficult by increasing the total amount of stored data in the storage location, with the multiple instances of writeover data obfuscating DD data. - A
notification module 340 provides notifications to other modules of thenode 140,other nodes 140, or external destinations (e.g., push notifications, mobile device notifications, emails, phone calls, text messages, etc.) when an event takes place. An event is a change in state in anode 140. Examples of events include data being written to a DD (including data being written to a DD a specified number of times), data being read from a DD (including data being read from a DD a specified number of times), data being deleted from a DD, data control functions (moving data, replicating data, archiving data, etc.), TTL functions (TTL expiration, TTL changes, TTL creation, TTL deletion, etc.), actions performed by a node, and time instances (a clock reading a particular time, a timer expiring, etc.). In one embodiment, thenotification module 340 of anode 140 receives a notification request from a module of thenode 140, adifferent node 140, arecipient 110, or another entity. The notification request specifies the event for which the notification is to be created. For events relating to DDs, the notification request includes the DDID and a token (e.g., owner token, read token) associated with the DDID. The notification request further includes a notification address to which a notification is to be made when the event occurs. In one embodiment, the notification address is specified in the form of a DDID and write token for a different DD in thedomain 130. The notification address may be specified as a different form of address, such as an address on the Internet to which an email or another form of message may be sent. - The
notification module 340 determines whether the token for a DDID in a notification request is correct. If the token is not correct, thenotification module 340 rejects or otherwise ignores the notification request. If the token is correct, thenotification module 340 examines the notification request to identify the type of event for which the notification is requested. Thenotification module 340 then creates a notification for the event. In one embodiment, thenotification module 340 establishes a trigger that detects when the appropriate type of event occurs for the identified DD. To this end, thenotification module 340 may monitor the activities of the other modules (e.g., the write module 315) to determine when such events occur. For example, if the notification request specifies a write event, thenotification module 340 may monitor thewrite module 315 to detect writes to the indicated DD. - When the requested event is detected, the
notification module 340 generates and sends a notification to the specified notification address. The notification may identify the DD to which the event occurs (e.g., by including the DDID in the notification) and the type of event that occurred (e.g., a write to the DD having the DDID). If the notification address is for a DD, thenotification module 340 acts as asender 120 and uses the write token and DDID specified in the notification request to write the notification to the DD. In this example, therecipient 110 or other entity that requested the notification can monitor a single DD to receive notifications about events occurring in multiple different DDs. If the notification address is specified as a different form of address, thenotification module 340 sends the notification using the appropriate technique for the address. - A geo-
fence module 345 receives and analyzes geographic-related restrictions associated with the DD or requests received by the DD. The geo-fence module 345 communicates with the other modules in the DD to enforce such restrictions. The restrictions may specify that a DD is only accessible by senders and recipients within a geographic area specified by the creator of the DD. Access may be restricted in various ways in different embodiments. For example, in one embodiment, requests received by a DD may be valid only if the originator of the request is located within a certain geographic area. In another embodiment, a DD or specific contents of the DD may be accessible only if a specified party (e.g., owner, recipient, sender, third party, etc.) is within a certain geographic area. The geo-fence module 345 may also communicate with thenotification module 340 to send notifications when events (e.g., write requests, read requests, etc.) occur within specified geographic areas. - A
monitoring module 350 detects events and sends action messages to anaction module 355 upon detection. Themonitoring module 350 can monitor events within thenode 140 or outside of thenode 140, such as at adifferent node 140. To monitor events occurring outside of thenode 140, themonitoring module 350 may send a notification request to one ormore notification modules 340 ofother nodes 140. The notification request may identify the event for which notification is requested and include a notification address identifying the node making the request. The notification request is received by anotification module 340 of the other node, and a notification is sent to, and received by, themonitoring module 350 in the first node when the event occurs. To monitor events within thenode 140, themonitoring module 350 may send a notification request to thenotification module 340 of thenode 140, or the monitoring module may communicate directly with other modules of thenode 140 to determine when the event occurs. - Trigger messages specify events to be monitored and actions to be performed if the events are detected. Trigger messages may be sent by users, system administrators, software developers, other modules of the
node 140,other nodes 140, applications, etc. Trigger messages are received by themonitoring module 350, and the monitoring module monitors the specified events. In one embodiment, trigger message contents are stored in thedata storage 390. In another embodiment, trigger message contents are stored in a DD accessible to themonitoring module 350 and theaction module 355. - The
action module 355 performs actions when events are detected. An action is a function performed in response to a change in state in anode 140. Examples of actions include notifications, notification requests, command sequences, writing to a DD, reading from a DD, deleting data from a DD, deleting a DD, data control functions (moving data, replicating data, archiving data, etc.), TTL functions (TTL expiration, TTL changes, TTL creation, TTL deletion, etc.), and sending messages (e.g., to address on the Internet to which an email or another form of message may be sent). Command sequences may include instructions sent to systems or devices connected to thenode 140. Theaction module 355 is informed by themonitoring module 350 when an event is detected, and performs the actions specified in a trigger message. - In one embodiment, events and actions are connected to perform multiple actions in sequence upon detection of an event. A first action performed in response to a first event may also be specified as a second event with a corresponding second action. For example, a first trigger message specifies a first event as a read from a first DD and a first action as a write operation a second DD. Accordingly, when the first DD is read from, the second DD is written to. A second trigger message specifies a second event as a write operation to the second DD and a second action as an email to an email address.
- A
scheduling module 360 determines when an action is performed relative to an event. In one embodiment, a trigger message includes a specified time at which an action occurs. The specified time may be expressed as a counter (e.g., a duration of time after the event is detected) or as a timestamp (e.g., an explicit time at which the action occurs). In another embodiment, an event is a time instance, such as a timer expiring or a clock reaching a certain time. Thescheduling module 360 communicates with theaction module 355 to perform the action at the specified time. For example, upon detection of an event, thescheduling module 360 may instruct theaction module 355 to wait to perform the action until the specified time or until further instructions are received from the scheduling module. - A handshake module 365 facilitates direct connections between two or
more nodes 140 that may otherwise be unable to connect due to network security policies, such as firewall policies. In one embodiment, the handshake module 365 performs dual functions. First, a handshake module located in ahandshake node 140 provides functionality allowing establishment of a direct connection between two other nodes using respective handshake modules in the other two nodes. Second, the handshake module 365 in anode 140 establishes a direct connection with the handshake module of another node by exchanging data using the handshake module of a handshake node. In other embodiments, the handshake module 365 may perform only one of these functions and/or perform additional functions. - An embodiment of the handshake module 365 performs the first function—allowing two other nodes to establish a direct connection—by exchanging handshake information between the two nodes. Handshake data may include network address information such as IP addresses and port addresses and/or information describing characteristics of the nodes. In one embodiment, the handshake module 365 within the handshake node allows for the creation of a DD for the purpose of exchanging handshake information. The node on whose behalf the DD is created receives the associated DDID and may provide the DDID to the other node with which the direct connection is to be established. The two nodes that will be party to the direct connection may then exchange handshake information using the handshake node.
- An embodiment of the handshake module 365 performs the second function—establishing a direct connection with the handshake module of another node—identifying a handshake node that can be used to exchange information with the other node. In one embodiment, the handshake module 365 maintains a directory of handshake nodes. The handshake module 365 selects a particular handshake node from the directory and exchanges the identity of the selected handshake node with the handshake module of the other node via an indirect connection. Once the handshake modules 365 of the two nodes know the identity of the handshake node, the handshake modules 365 respectively connect to the handshake node to exchange information and establish a direct connection.
-
FIG. 4 is a flowchart illustrating steps for using a DD to pass data from asender 120 to arecipient 110 according to one embodiment.FIG. 4 describes the steps from the perspective of anode 140 of adomain 130. Other embodiments may include different and/or other steps than those described herein, and the steps may be performed in different orders. Likewise, some or all of the steps may be performed by entities other than thenode 140 in other embodiments. - The
node 140 receives 410 a create request. As described above, arecipient 110 can issue the create request and send the request to aningress node 140A in thedomain 130. Theingress node 140A randomly selects a node to service the request. Assume, then, that thenode 140 receives 410 the create request after having been randomly selected to service it. In response to the create request, thenode 140 generates 415 a DDID and a set of associated tokens for the new DD. In addition, thenode 140 may allocate storage space for storing data written to the DD. Thenode 140 provides the tokens and DDID to therecipient 110. - Subsequently, the
node 140 receives 420 a write request including the DDID and associated write token. The write request may have been issued by asender 120 who received the DDID and write token from therecipient 110. Thesender 120 sends the write request to aningress node 140L in thedomain 130 which, in turn, forwards the write request to other nodes in the domain until it reaches the node that created the DD associated with the DDID. Thenode 140 determines whether the write token is valid. If the token is valid, thenode 140 responds to the write request by establishing a connection with the sender'singress node 140L. Thenode 140 receives the data to be written to the DD from thesender 120 via theingress node 140L andstores 425 the data in the DD. If the token is not valid, an embodiment of thenode 140 does not respond to the write request. In another embodiment, if the token is not valid, thenode 140 sends a message indicating the request is rejected. - The
node 140 later receives 430 a read request including the DDID and associated read token. The read request may have been issued by therecipient 110 who established the DD identified by the DDID. Similar to a write request, therecipient 110 sends the read request to aningress node 140A in thedomain 130 which forwards the read request to other nodes in the domain until it reaches the node that created the DD associated with the DDID. Upon receiving the read request, thenode 140 determines whether the read token is valid. If the token is valid, thenode 140 responds to the read request by establishing a connection with the recipient'singress node 140A and sends it the data from the DD. For example, if the DD is maintained as a queue, thenode 140 will send the data that is next in the queue. If the token is not valid, an embodiment of thenode 140 does not respond to the read request. In another embodiment, if the token is not valid, thenode 140 sends a message indicating the request is rejected. -
FIG. 5 is a flowchart illustrating steps for using a DD to monitor events and perform actions if an event is detected according to one embodiment. A trigger message is received 505 by themonitoring module 350. The trigger message specifies an event to be monitored, and one or more actions to be performed if the event is detected. The trigger message may be stored indata storage 390 or a DD. Responsive to the trigger message being received, themonitoring module 350 begins 510 monitoring for the occurrence of the event. For example, themonitoring module 350 may send one or more notification requests to monitor the event, or a timer or clock may be set by thescheduling module 360. When the event occurs, the event is detected 515 by themonitoring module 350. Themonitoring module 350 informs 520 theaction module 355 that the event has occurred. Theaction module 355 determines the set of actions associated with the event by the trigger message and performs 525 the actions. In one embodiment, when the action module performs the set of actions, themonitoring module 350 deletes the trigger record such that the action only occurs once in response to the event detection. In another embodiment, the trigger record persists, allowing the set of actions to be performed each time the event is detected. -
FIG. 6 is a high-level block diagram illustrating an example of two nodes establishing a direct connection according to one embodiment. Specifically,FIG. 6 illustrates afirst node 140X establishing a direct connection with asecond node 140Y.FIG. 6 also illustrates ahandshake node 140Z. InFIG. 6 ,nodes network security systems node 140. The twonodes network security systems handshake node 140Z. - In one embodiment, the
node 140X establishing the direct connection accesses the handshake directory which is maintained, or otherwise accessible via, the node's handshake module 365. Thenode 140X selects thehandshake node 140Z, and sends an identifier of the selected handshake node to theother node 140Y that will be party to the direct connection. Thenode 140X may send the identifier of thehandshake node 140Z to the other node using an indirect connection over theDD domain 130, using standard networking communications, and/or via other techniques. In one embodiment, thenode 140Y that receives a direct connection request with an identifier of ahandshake node 140Z will verify that the handshake node is also included in its handshake directory. Once ahandshake node 140Z is selected and known to bothnodes nodes handshake node 140Z. -
FIG. 7 is a high-level block diagram illustrating physical components of acomputer 700 used as part or all of one or more of the entities described herein in one embodiment. For example, instances of the illustratedcomputer 700 may be used as therecipient 110,sender 120, and/or anode 140 in thedomain 130. Illustrated are at least oneprocessor 702 coupled to achipset 704. Also coupled to thechipset 704 are amemory 706, astorage device 708, akeyboard 710, a graphics adapter 712, apointing device 714, and anetwork adapter 716. Adisplay 718 is coupled to the graphics adapter 712. In one embodiment, the functionality of thechipset 704 is provided by amemory controller hub 720 and an I/O controller hub 722. In another embodiment, thememory 706 is coupled directly to theprocessor 702 instead of thechipset 704. In one embodiment, one or more sound devices (e.g., a loudspeaker, audio driver, etc.) is coupled tochipset 704. - The
storage device 708 is any non-transitory computer-readable storage medium, such as a hard drive, compact disk read-only memory (CD-ROM), DVD, or a solid-state memory device. Thememory 706 holds instructions and data used by theprocessor 702. Thepointing device 714 may be a mouse, track ball, or other type of pointing device, and is used in combination with thekeyboard 710 to input data into thecomputer 700. The graphics adapter 712 displays images and other information on thedisplay 718. Thenetwork adapter 716 couples thecomputer system 700 to a local or wide area network. - As is known in the art, a
computer 700 can have different and/or other components than those shown inFIG. 7 . In addition, thecomputer 700 can lack certain illustrated components. In one embodiment, acomputer 700 acting as anode 140 may lack akeyboard 710, pointingdevice 714, graphics adapter 712, and/ordisplay 718. Moreover, thestorage device 708 can be local and/or remote from the computer 700 (such as embodied within a storage area network (SAN)). - As is known in the art, the
computer 700 is adapted to execute computer program modules for providing functionality described herein. As used herein, the term “module” refers to computer program logic utilized to provide the specified functionality. Thus, a module can be implemented in hardware, firmware, and/or software. In one embodiment, program modules are stored on thestorage device 708, loaded into thememory 706, and executed by theprocessor 702. - The above description is included to illustrate the operation of certain embodiments and is not meant to limit the scope of the invention. From the above discussion, many variations will be apparent to one skilled in the relevant art that would yet be encompassed by the spirit and scope of the invention.
Claims (20)
1. A method for exchanging data between a sender and a recipient comprising:
receiving, at a second node of a plurality of nodes of a dead drop domain, from the sender via a first node of the plurality of nodes of the dead drop domain, a write request to write data to a specified dead drop of a plurality of dead drops in the dead drop domain, wherein each dead drop of the plurality of dead drops is a distinct storage location on a node of the plurality of nodes and identified by a unique dead drop identifier (DDID), each node of the plurality of nodes comprising a processor and a memory and connected to one or more other nodes via a network;
determining that the specified dead drop is on the second node;
writing the data to the specified dead drop on the second node;
receiving a read request to read data from the specified dead drop, the read request made by the recipient and received at the second node from a third node of the plurality of nodes of the dead drop domain; and
providing the data from the specified dead drop to the recipient in response to the read request.
2. The method of claim 1 , further comprising:
receiving, at the second node, a create request from the recipient;
creating the specified dead drop at the second node in response to the create request;
generating a DDID identifying the specified dead drop, a write token associated with the specified dead drop, and a read token associated with the specified dead drop; and
providing the DDID identifying the specified dead drop, the write token, and the read token to the recipient.
3. The method of claim 2 , wherein writing the data to the specified dead drop comprises:
comparing a write token received from the sender as part of the write request with the write token associated with the specified dead drop;
determining that the write token received from the sender is valid based on the comparison; and
writing the data to the specified dead drop responsive to determining that the write token from the sender is valid.
4. The method of claim 2 , wherein providing the data from the specified dead drop to the recipient comprises:
comparing a read token received from the recipient with the read token associated with the specified dead drop;
determining that the read token received from the recipient is valid based on the comparison; and
providing the data from the specified dead drop to the recipient in response to determining that the read token is valid.
5. The method of claim 2 , wherein determining that the specified dead drop is on the second node comprises:
comparing a DDID included in the write request with the DDID identifying the specified dead drop; and
determining that the specified dead drop is on the second node based on the comparison.
6. The method of claim 1 , further comprising:
evaluating a time-to-live (TTL) information for the specified dead drop at the second node of the dead drop domain;
determining whether a duration for the specified dead drop indicated by the TTL information has been reached; and
deleting the specified dead drop from the second node responsive to a determination that the duration for the dead drop indicated by the TTL information has been reached.
7. The method of claim 1 , further comprising:
receiving, at the second node of the dead drop domain, a notification request for the specified dead drop;
examining the notification request to identify a type of event for which a notification is requested and a notification address to which the notification is to be made; and
creating a trigger that causes the notification to be sent to the notification address responsive to the identified type of event occurring at the specified dead drop.
8. A system for exchanging data between a sender and a recipient comprising:
a processor for executing computer program instructions; and
a non-transitory computer-readable storage medium storing computer program instructions executable by the processor to perform operations comprising:
receiving, at a second node of a plurality of nodes of a dead drop domain, from the sender via a first node of the plurality of nodes of the dead drop domain, a write request to write data to a specified dead drop of a plurality of dead drops in the dead drop domain, wherein each dead drop of the plurality of dead drops is a distinct storage location on a node of the plurality of nodes and identified by a unique dead drop identifier (DDID), each node of the plurality of nodes comprising a processor and a memory and connected to one or more other nodes via a network;
determining that the specified dead drop is on the second node;
writing the data to the specified dead drop on the second node;
receiving a read request to read data from the specified dead drop, the read request made by the recipient and received at the second node from a third node of the plurality of nodes of the dead drop domain; and
providing the data from the specified dead drop to the recipient in response to the read request.
9. The system of claim 8 , the operations further comprising:
receiving, at the second node, a create request from the recipient;
creating the specified dead drop at the second node in response to the create request;
generating a DDID identifying the specified dead drop, a write token associated with the specified dead drop, and a read token associated with the specified dead drop; and
providing the DDID identifying the specified dead drop, the write token, and the read token to the recipient.
10. The system of claim 9 , wherein writing the data to the specified dead drop comprises:
comparing a write token received from the sender as part of the write request with the write token associated with the specified dead drop;
determining that the write token received from the sender is valid based on the comparison; and
writing the data to the specified dead drop responsive to determining that the write token from the sender is valid.
11. The system of claim 9 , wherein providing the data from the specified dead drop to the recipient comprises:
comparing a read token received from the recipient with the read token associated with the specified dead drop;
determining that the read token received from the recipient is valid based on the comparison; and
providing the data from the specified dead drop to the recipient in response to determining that the read token is valid.
12. The system of claim 9 , wherein determining that the specified dead drop is on the second node comprises:
comparing a DDID included in the write request with the DDID identifying the specified dead drop; and
determining that the specified dead drop is on the second node based on the comparison.
13. The system of claim 8 , the operations further comprising:
evaluating a time-to-live (TTL) information for the specified dead drop at the second node of the dead drop domain;
determining whether a duration for the specified dead drop indicated by the TTL information has been reached; and
deleting the specified dead drop from the second node responsive to a determination that the duration for the dead drop indicated by the TTL information has been reached.
14. The system of claim 8 , the operations further comprising:
receiving, at the second node of the dead drop domain, a notification request for the specified dead drop;
examining the notification request to identify a type of event for which a notification is requested and a notification address to which the notification is to be made; and
creating a trigger that causes the notification to be sent to the notification address responsive to the identified type of event occurring at the specified dead drop.
15. A non-transitory computer-readable storage medium storing computer program instructions executable by a processor to perform operations for exchanging data between a sender and a recipient, the operations comprising:
receiving, at a second node of a plurality of nodes of a dead drop domain, from the sender via a first node of the plurality of nodes of the dead drop domain, a write request to write data to a specified dead drop of a plurality of dead drops in the dead drop domain, wherein each dead drop of the plurality of dead drops is a distinct storage location on a node of the plurality of nodes and identified by a unique dead drop identifier (DDID), each node of the plurality of nodes comprising a processor and a memory and connected to one or more other nodes via a network;
determining that the specified dead drop is on the second node;
writing the data to the specified dead drop on the second node;
receiving a read request to read data from the specified dead drop, the read request made by the recipient and received at the second node from a third node of the plurality of nodes of the dead drop domain; and
providing the data from the specified dead drop to the recipient in response to the read request.
16. The non-transitory computer-readable storage medium of claim 15 , the operations further comprising:
receiving, at the second node, a create request from the recipient;
creating the specified dead drop at the second node in response to the create request;
generating a DDID identifying the specified dead drop, a write token associated with the specified dead drop, and a read token associated with the specified dead drop; and
providing the DDID identifying the specified dead drop, the write token, and the read token to the recipient.
17. The non-transitory computer-readable storage medium of claim 16 , the operations further comprising:
comparing a write token received from the sender as part of the write request with the write token associated with the specified dead drop;
determining that the write token received from the sender is valid based on the comparison; and
writing the data to the specified dead drop responsive to determining that the write token from the sender is valid.
18. The non-transitory computer-readable storage medium of claim 16 , wherein providing the data from the specified dead drop to the recipient comprises:
comparing a read token received from the recipient with the read token associated with the specified dead drop;
determining that the read token received from the recipient is valid based on the comparison; and
providing the data from the specified dead drop to the recipient in response to determining that the read token is valid.
19. The non-transitory computer-readable storage medium of claim 16 , wherein determining that the specified dead drop is on the second node comprises:
comparing a DDID included in the write request with the DDID identifying the specified dead drop; and
determining that the specified dead drop is on the second node based on the comparison.
20. The non-transitory computer-readable storage medium of claim 15 , the operations further comprising:
receiving, at the second node of the dead drop domain, a notification request for the specified dead drop;
examining the notification request to identify a type of event for which a notification is requested and a notification address to which the notification is to be made; and
creating a trigger that causes the notification to be sent to the notification address responsive to the identified type of event occurring at the specified dead drop.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/152,362 US20190044796A1 (en) | 2015-04-22 | 2018-10-04 | Dead drop network architecture |
Applications Claiming Priority (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201562151188P | 2015-04-22 | 2015-04-22 | |
US201562193927P | 2015-07-17 | 2015-07-17 | |
US201562193930P | 2015-07-17 | 2015-07-17 | |
US201562214124P | 2015-09-03 | 2015-09-03 | |
US15/136,347 US9729390B2 (en) | 2015-04-22 | 2016-04-22 | Dead drop network architecture |
US15/640,211 US10116495B2 (en) | 2015-04-22 | 2017-06-30 | Dead drop network architecture |
US16/152,362 US20190044796A1 (en) | 2015-04-22 | 2018-10-04 | Dead drop network architecture |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/640,211 Continuation US10116495B2 (en) | 2015-04-22 | 2017-06-30 | Dead drop network architecture |
Publications (1)
Publication Number | Publication Date |
---|---|
US20190044796A1 true US20190044796A1 (en) | 2019-02-07 |
Family
ID=57144652
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/136,311 Active US9667477B2 (en) | 2015-04-22 | 2016-04-22 | Dead drop network architecture |
US15/136,347 Active US9729390B2 (en) | 2015-04-22 | 2016-04-22 | Dead drop network architecture |
US15/640,211 Expired - Fee Related US10116495B2 (en) | 2015-04-22 | 2017-06-30 | Dead drop network architecture |
US16/152,362 Abandoned US20190044796A1 (en) | 2015-04-22 | 2018-10-04 | Dead drop network architecture |
Family Applications Before (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/136,311 Active US9667477B2 (en) | 2015-04-22 | 2016-04-22 | Dead drop network architecture |
US15/136,347 Active US9729390B2 (en) | 2015-04-22 | 2016-04-22 | Dead drop network architecture |
US15/640,211 Expired - Fee Related US10116495B2 (en) | 2015-04-22 | 2017-06-30 | Dead drop network architecture |
Country Status (4)
Country | Link |
---|---|
US (4) | US9667477B2 (en) |
EP (2) | EP3286651A4 (en) |
CN (2) | CN107710219A (en) |
WO (2) | WO2016172597A1 (en) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9667477B2 (en) * | 2015-04-22 | 2017-05-30 | LARC Networks, Inc. | Dead drop network architecture |
US10673823B2 (en) * | 2016-10-17 | 2020-06-02 | Microsoft Technology Licensing, Llc | Migration containers |
US11102231B2 (en) * | 2017-03-22 | 2021-08-24 | Palo Alto Network, Inc. | Distributed scanning |
US10635838B1 (en) * | 2017-07-31 | 2020-04-28 | EMC IP Holding Company LLC | Cloud based dead drop for isolated recovery systems |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140115329A1 (en) * | 2012-08-31 | 2014-04-24 | Pkware, Inc. | Systems and methods for data verifcation and replay prevention |
US20140281526A1 (en) * | 2013-03-15 | 2014-09-18 | Ty Brendan Lindteigen | Secure Network Storage |
US20160087995A1 (en) * | 2013-05-13 | 2016-03-24 | Telefonaktiebolaget L M Ericsson (Publ) | Procedure For Platform Enforced Storage in Infrastructure Clouds |
Family Cites Families (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5237684A (en) * | 1991-08-12 | 1993-08-17 | International Business Machines Corporation | Customized and versatile event monitor within event management services of a computer system |
US20030133417A1 (en) * | 1997-03-12 | 2003-07-17 | Sig H. Badt | Method and message therefor of monitoring the spare capacity of a dra network |
US6088804A (en) * | 1998-01-12 | 2000-07-11 | Motorola, Inc. | Adaptive system and method for responding to computer network security attacks |
US6366926B1 (en) | 1998-12-31 | 2002-04-02 | Computer Associates Think, Inc. | Method and apparatus for the dynamic filtering and routing of events |
US6954753B1 (en) | 1999-10-20 | 2005-10-11 | Hewlett-Packard Development Company, L.P. | Transparent electronic safety deposit box |
US6654782B1 (en) | 1999-10-28 | 2003-11-25 | Networks Associates, Inc. | Modular framework for dynamically processing network events using action sets in a distributed computing environment |
US7370004B1 (en) | 1999-11-15 | 2008-05-06 | The Chase Manhattan Bank | Personalized interactive network architecture |
KR100524952B1 (en) | 2003-03-07 | 2005-11-01 | 삼성전자주식회사 | Method for protecting data of recordable medium and disk drive using the same |
US7587366B2 (en) | 2004-10-14 | 2009-09-08 | International Business Machines Corporation | Secure information vault, exchange and processing system and method |
US20070208823A1 (en) * | 2006-02-17 | 2007-09-06 | Marvin Shannon | System and Method for Making a Data Silo to Distribute Electronic Data |
US20090254392A1 (en) * | 2006-03-30 | 2009-10-08 | Zander Van S | Method and system for enterprise network access control and management for government and corporate entities |
US7840969B2 (en) | 2006-04-28 | 2010-11-23 | Netapp, Inc. | System and method for management of jobs in a cluster environment |
US20080307525A1 (en) | 2007-06-05 | 2008-12-11 | Computer Associates Think, Inc. | System and method for evaluating security events in the context of an organizational structure |
WO2009032712A2 (en) | 2007-08-29 | 2009-03-12 | Nirvanix, Inc. | Method and system for moving requested files from one storage location to another |
US8353016B1 (en) | 2008-02-29 | 2013-01-08 | Adobe Systems Incorporated | Secure portable store for security skins and authentication information |
US8082224B2 (en) * | 2008-07-16 | 2011-12-20 | Business Objects S.A. | Systems and methods to provide business information via a push model |
US8060792B2 (en) | 2009-03-31 | 2011-11-15 | Amazon Technologies, Inc. | Monitoring and automated recovery of data instances |
US8572282B2 (en) * | 2009-10-30 | 2013-10-29 | Cleversafe, Inc. | Router assisted dispersed storage network method and apparatus |
US8819452B2 (en) * | 2009-11-25 | 2014-08-26 | Cleversafe, Inc. | Efficient storage of encrypted data in a dispersed storage network |
US9350705B2 (en) * | 2010-06-25 | 2016-05-24 | Salesforce.Com, Inc. | Methods and systems for providing a token-based application firewall correlation |
US9336402B2 (en) * | 2010-09-13 | 2016-05-10 | City University Of Hong Kong | Secure data in removable storage devices via encryption token(s) |
US8990563B2 (en) * | 2010-09-15 | 2015-03-24 | Telefonaktiebolaget L M Ericsson (Publ) | Sending protected data in a communication network |
US9177169B2 (en) * | 2012-02-13 | 2015-11-03 | Wwpass Corporation | Secure digital storage |
WO2013122869A1 (en) * | 2012-02-13 | 2013-08-22 | Eugene Shablygin | Sharing secure data |
WO2013123548A2 (en) * | 2012-02-20 | 2013-08-29 | Lock Box Pty Ltd. | Cryptographic method and system |
US20130227352A1 (en) * | 2012-02-24 | 2013-08-29 | Commvault Systems, Inc. | Log monitoring |
WO2013170316A1 (en) | 2012-05-18 | 2013-11-21 | Demand Solutions Consulting Pty Ltd | System and method for object delivery and pickup |
US9867116B2 (en) | 2012-12-20 | 2018-01-09 | Comcast Cable Communications, Llc | Network awareness of device location |
US10334037B2 (en) | 2014-03-31 | 2019-06-25 | Yaana Technologies, Inc. | Peer-to-peer rendezvous system for minimizing third party visibility and method thereof |
US9667477B2 (en) * | 2015-04-22 | 2017-05-30 | LARC Networks, Inc. | Dead drop network architecture |
US9699197B2 (en) * | 2015-07-17 | 2017-07-04 | LARC Networks, Inc. | Double write data exchange in a dead drop network architecture |
-
2016
- 2016-04-22 US US15/136,311 patent/US9667477B2/en active Active
- 2016-04-22 WO PCT/US2016/029002 patent/WO2016172597A1/en unknown
- 2016-04-22 CN CN201680036002.3A patent/CN107710219A/en active Pending
- 2016-04-22 CN CN201680036055.5A patent/CN107710218A/en active Pending
- 2016-04-22 EP EP16784008.1A patent/EP3286651A4/en not_active Withdrawn
- 2016-04-22 US US15/136,347 patent/US9729390B2/en active Active
- 2016-04-22 EP EP16784006.5A patent/EP3286686A4/en not_active Withdrawn
- 2016-04-22 WO PCT/US2016/029005 patent/WO2016172600A1/en unknown
-
2017
- 2017-06-30 US US15/640,211 patent/US10116495B2/en not_active Expired - Fee Related
-
2018
- 2018-10-04 US US16/152,362 patent/US20190044796A1/en not_active Abandoned
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140115329A1 (en) * | 2012-08-31 | 2014-04-24 | Pkware, Inc. | Systems and methods for data verifcation and replay prevention |
US20140281526A1 (en) * | 2013-03-15 | 2014-09-18 | Ty Brendan Lindteigen | Secure Network Storage |
US20160087995A1 (en) * | 2013-05-13 | 2016-03-24 | Telefonaktiebolaget L M Ericsson (Publ) | Procedure For Platform Enforced Storage in Infrastructure Clouds |
Also Published As
Publication number | Publication date |
---|---|
US10116495B2 (en) | 2018-10-30 |
US20170310540A1 (en) | 2017-10-26 |
US9729390B2 (en) | 2017-08-08 |
US20160315843A1 (en) | 2016-10-27 |
CN107710218A (en) | 2018-02-16 |
EP3286651A1 (en) | 2018-02-28 |
WO2016172597A1 (en) | 2016-10-27 |
US9667477B2 (en) | 2017-05-30 |
EP3286686A4 (en) | 2018-12-19 |
US20160314307A1 (en) | 2016-10-27 |
WO2016172600A1 (en) | 2016-10-27 |
EP3286651A4 (en) | 2018-12-19 |
CN107710219A (en) | 2018-02-16 |
EP3286686A1 (en) | 2018-02-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9917847B2 (en) | Double write data exchange in a dead drop network architecture | |
US20230361988A1 (en) | Sharing Encrypted Documents Within and Outside an Organization | |
US20190044796A1 (en) | Dead drop network architecture | |
US9825945B2 (en) | Preserving data protection with policy | |
US10742586B2 (en) | Assured encrypted delivery | |
US20180367308A1 (en) | User authentication in a dead drop network domain | |
CN114641965A (en) | Secure data exchange network | |
US20060230459A1 (en) | System and method for password protecting an attribute of content transmitted over a network | |
US20170054789A1 (en) | System and method for sending electronic files in response to inbound file requests | |
US11546411B1 (en) | Backing up confidential data to user devices on the same local network | |
US9407641B2 (en) | Service access control | |
JP2006107158A (en) | Storage network system and access control method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |