Data diode for enhanced data security

Abstract

Data diode systems and methods for enhancing data security are disclosed herein. Encrypted data transmitted from a first node (e.g., an entity coupled to a network) is received. The transmitted data is encrypted with a public key associated with a second node (e.g., a node to which encrypted data is transmitted). The encrypted data is decrypted using a private key associated with the second node to generate decrypted data. It is determined whether the digital signature in the decrypted data corresponds to a ledger entry mapped to a first node in the first ledger entry set. The first node is validated as a trusted entity based on the digital signature having been determined to correspond to the ledger entry. Based on the verification, it is determined that the transmission of encrypted data from the first node is an allowable data transmission.

Description

Background Technology

[0001] Data security on communication links is becoming increasingly important. For example, in high-security environments such as defensive environments, different entities coupled to the network encompass different security categories. Because these environments typically involve confidential information, securing the network is a high priority against potential malicious actors. Conventional technologies employ air gaps to isolate the network from the external environment. However, with the increasing amount of data that can be transmitted and the growing importance of continuous and / or real-time data streams, individual air gaps are becoming insufficient.

[0002] To address these issues, physical devices known as data diodes, which implement photodiodes, are mounted on communication links (e.g., wires) to allow data to travel in a single direction (e.g., from a lower-security entity to a higher-security entity, rather than the other way around). While such devices improve security, their installation and / or reconfiguration are costly and cumbersome. Summary of the Invention

[0003] This summary is provided to introduce, in a simplified form, some concepts that will be further described in the following detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0004] This document discloses a data diode system and method for enhancing data security. Encrypted data is received from a first node (e.g., an entity coupled to a network). The transmitted data is encrypted using a public key associated with a second node (e.g., the node to which the encrypted data was transmitted). The encrypted data is decrypted using a private key associated with the second node to generate decrypted data. A digital signature in the decrypted data is determined to correspond to a ledger entry of the first node mapped to a first set of ledger entries. Based on the confirmation that the digital signature corresponds to a ledger entry in the first set of ledger entries, the first node is verified as a trusted entity. Based on this verification, the transmission of encrypted data from the first node is determined to be permissible data transmission. Attached Figure Description

[0005] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate embodiments of the present application and, together with the description, further serve to explain the principles of the embodiments and enable those skilled in the art to make and use the embodiments.

[0006] Figure 1A A block diagram of a data diode system according to an example embodiment is shown.

[0007] Figure 1B A block diagram of another data diode system according to an example embodiment is shown.

[0008] Figure 2 A block diagram depicts another data diode system according to an embodiment.

[0009] Figure 3 A flowchart of a method for implementing a data diode according to an example embodiment is shown.

[0010] Figure 4 A flowchart of a method for transmitting data to a third node according to an example embodiment is shown.

[0011] Figure 5 A flowchart of a method for updating a first set of ledger entries according to an example embodiment is shown.

[0012] Figure 6 A flowchart of a method for performing data diodes in a region, according to an example embodiment, is shown.

[0013] Figure 7A A block diagram of a data diode system operating in a region according to an example embodiment is shown.

[0014] Figure 7B An exemplary data diode ledger is shown according to an exemplary embodiment.

[0015] Figure 8 A block diagram of an example computer system in which embodiments can be implemented is shown.

[0016] The subject matter of this application will now be described with reference to the accompanying drawings. In the drawings, the same reference numerals indicate the same or similarly functional elements. Additionally, the leftmost numeral(s) of the reference numeral(s) identifies the drawing in which the reference numeral(s) first appear. Detailed Implementation I. Introduction

[0017] Numerous exemplary embodiments are disclosed in detail below. The scope of this patent application is not limited to the disclosed embodiments, but also includes combinations of embodiments of this disclosure, as well as modifications thereof. It should be noted that any part / subpart heading provided herein is not intended to be limiting. Embodiments are described throughout this document, and any type of embodiment may be included under any part / subpart. Furthermore, embodiments disclosed in any part / subpart may be combined in any manner with any other embodiments described in the same part / subpart and / or different parts / subparts. II. Example Implementation

[0018] Data security on communication links is becoming increasingly important. For example, in high-security environments such as defensive environments, different entities coupled to the network encompass different security categories. Because these environments typically involve confidential information, ensuring the network is protected against potential malicious actors is a high priority. Conventional technologies employ air gaps to isolate the network from the external environment. However, with the increasing amount of data that can be transmitted and the growing importance of continuous and / or real-time data streams, air gaps alone become insufficient.

[0019] To address these issues, physical devices known as data diodes, which implement photodiodes, are mounted on communication links (e.g., wires) to allow data to travel in a single direction (e.g., from a lower-security entity to a higher-security entity, rather than the opposite direction). While such devices improve security, their installation and / or reconfiguration are expensive and cumbersome. Furthermore, each individual path to be controlled (e.g., in both directions) requires the installation and / or maintenance of separate hardware.

[0020] The embodiments described herein point to a data diode (e.g., a virtual data diode) for enhancing data security. In example embodiments, the data diode of this disclosure can be used to ensure that data is transmitted between nodes in only a single direction. In an example system, encrypted data is received from a first node (e.g., an entity coupled to the network). The transmitted data is encrypted using a public key associated with a second node (e.g., the node to which the encrypted data was transmitted). The encrypted data is decrypted using a private key associated with the second node to generate decrypted data. It is determined whether a digital signature in the decrypted data corresponds to a ledger entry of the first node mapped to a first set of ledger entries. Based on the determination that the digital signature corresponds to a ledger entry in the first set of ledger entries, the first node is verified as a trusted entity. Based on this verification, the transmission of encrypted data from the first node is determined to be permissible data transmission.

[0021] The techniques described herein enable the virtual implementation of data diodes, which can be used to replace or be attached to physical data diodes (e.g., separately) to enhance data security. A ledger of identities and credentials (e.g., public keys), and a data diode ledger indicating permitted data transfers, are maintained in a tamper-proof manner and used to enforce unidirectional communication between entities (e.g., nodes in a network) on a communication link. In other words, the ledger uses the information contained therein to indicate which entities are allowed to communicate with each other and in what direction. For example, a data diode ledger could indicate that entities with lower security levels are allowed to transfer information to entities with higher security levels, rather than the other way around. Based on these techniques, data diode functionality can be implemented securely without the additional hardware required by conventional methods (e.g., physical data diode devices).

[0022] Therefore, the techniques described herein advantageously provide improvements over other techniques, namely data encryption and security. For example, by utilizing ledgers with identities and credentials, as well as data diode ledgers as described herein, to manage permissible data flows between network nodes, unauthorized entities (e.g., malicious actors) are prevented from accessing systems coupled to the network, thereby maintaining the security of data transmitted between nodes and / or stored on various systems coupled to the network. Furthermore, by allowing only authorized communication between nodes, unauthorized manipulation of nodes and / or systems on the network (e.g., to execute attacks) can also be prevented, thereby ensuring the proper functioning of those network entities. In this way, unrestricted access to data and / or systems on the network is reduced or even eliminated. By mitigating or eliminating such access to network entities (including restricting the direction of communication occurring on the network), unnecessary expenditures on computing resources associated with such entities (e.g., central processing units (CPUs), storage devices, memory, power supplies, etc.) are also mitigated. Therefore, the embodiments described herein also improve the functionality of computing entities that utilize / maintain such computing resources by conserving such computing resources by preventing malicious entities from exploiting them (e.g., for improper purposes).

[0023] Furthermore, the advantage of the techniques described herein lies in their ability to virtually implement data diodes to control data flow, rather than using physical data diodes that are expensive and cumbersome to install and / or reconfigure. By implementing virtual data diodes according to embodiments of this disclosure, physical data diode devices can be eliminated in various environments, thereby enabling a reduction in the hardware used to control the directed flow of information between nodes in a network. Therefore, the techniques of this disclosure not only advantageously improve the utilization of computing resources, but also do so without the need for conventional physical data diode devices.

[0024] Implementation examples can be carried out in various environments and in various ways. For example, Figure 1A A block diagram of a data diode system 100 according to an example embodiment is shown. Figure 1A As shown, system 100 includes multiple nodes 102A-102N coupled to one or more networks 148 and a database (DB) host 140. Each node 102A-102N is any type of processing device, including, but not limited to: desktop computers, servers, mobile or handheld devices (e.g., tablet computers, personal digital assistants (PDAs), smartphones, laptops, etc.), Internet of Things (IoT) devices, or other suitable devices mentioned elsewhere herein or otherwise known.

[0025] In embodiments, DB host 140 includes one or more server computers or computing devices, which include one or more distributed or "cloud-based" servers. In embodiments, DB host 140 is associated with a cloud-based service platform, or is part of a cloud-based service platform, and in some embodiments, in addition to, or instead of, a cloud-based server, DB host 140 includes on-premises servers(s). DB host 140 is configured to host and execute any type of DB server application, such as, but not limited to, Microsoft Azure SQL Database from Redmond, Washington. TM In this embodiment, nodes 102A-102N and DB host 140 are communicatively coupled via one or more networks including one or more of a local area network (LAN), a wide area network (WAN), an enterprise network, the Internet, etc., and include one or more of wired and / or wireless portions of the network.

[0026] As used herein, a node includes any entity (which may include one or more processing devices) configured to receive and / or transmit information to or store information to another entity (e.g., another node). In some implementations, a node includes a collector node that collects information from a plurality of other nodes, or a broadcaster node that broadcasts information to a plurality of other nodes. In various embodiments, a node may be assigned a hierarchical level relative to other nodes (e.g., level 1, level 2, etc.). In some example implementations, a node includes (or is coupled to) devices that generate and / or record information, such as sensor devices that measure and / or observe various types of conditions (e.g., environmental conditions, computer or network status, etc.). In other example implementations, a node includes (or is coupled to) devices to be controlled, such as pumps, motors, actuators, machinery, computing devices, such that the node is configured to output control signals to control such devices.

[0027] like Figure 1A As shown, DB host 140 includes a signing key and a ledger database 144. Ledger database 144 includes an identity ledger 145 and multiple data diode ledgers 146. In this example, DB host 140 executes ledger database 144. Ledger database 144 provides tamper-proof capabilities for its database tables (e.g., identity ledger 145 and data diode ledgers 146), where parties with tamper-proof capabilities can cryptographically prove to other parties (such as auditors or other parties) that data maintained by the database has not been tampered with. Ledger database 144 protects data from any attacker or advanced user, including database administrators, system administrators, and cloud administrators. As with traditional ledgers, historical data is maintained. If a row in a ledger table is updated, its previous value is maintained and protected in the historical table. Ledger database 144 provides a record of all changes made to the database over time. According to an embodiment, historical data is maintained in relational form to support queries (e.g., SQL queries) for auditing, forensics, and other purposes.

[0028] In some example implementations, a data structure such as a Merkle tree is used, where rows modified by transactions in the ledger are crypto-hashed (e.g., SHA-256 hashed), and this data structure creates a root hash representing all rows in the transaction. The transactions processed by the ledger database 144 are then hashed together using the Merkle tree data structure. The result is the root hash of a block. The block is then hashed using the root hash of this block, along with the root hashes of previous blocks, as input to a hash function. This hash forms the blockchain. The root hash contains the crypto-hashed transactions and represents the state of the database at the time the digest is generated. According to embodiments, the digest is generated periodically and stored in a tamper-proof storage outside the database.

[0029] Ledger database 144 is configured to store and protect any type of data or information, including, but not limited to, identity ledger 145 and data diode ledger 146. Data diode ledger 146 is configured to store information for a given node indicating which other nodes can transmit data to the given node and / or which given node can transmit data to other nodes. In the example, data diode ledger 146 may use information that uniquely identifies the node (e.g., within an organization) to identify each node. Examples of node identifiers include, but are not limited to, node name, location, serial number, network address (e.g., Internet Protocol (IP) address or Media Access Control (MAC) address), and any other type of information that uniquely identifies the node. In some implementations, such as when the node is a device used by a user (e.g., a wearable device, telephone, sensor, or other computing device), the node identifier may include the user's email address, user's phone number, user's username, or any other information that uniquely identifies the user.

[0030] In the example, identity ledger 145 is maintained by an organization and includes ledgers across multiple nodes within that organization. In the example embodiment, identity ledger 145 is configured to store the identifier of each node (e.g., using a unique identifier within the organization) and the long-term signing key (e.g., a public signing key) associated with the node's identity. According to the embodiment, identity ledger 145 is also configured to store, for each node, a short-term encryption key (e.g., a public encryption key), which will be further described below.

[0031] In the example, each organization maintains and / or publishes its own data diode ledger, which includes the identity and (multiple) keys for the organization's nodes. In this way, each organization acts as its own identity or authentication authority. Using data diodes, each node of an organization can securely send and / or receive information from certain other nodes, as further described below.

[0032] To initially generate the data diode ledger 146 for a given node, the organization identifies a set of nodes capable of transmitting information to the given node, and / or a set of nodes to which the given node can transmit information. In some implementations, the given node is only allowed to receive information from one or more other nodes. In some other implementations, the given node is only allowed to transmit information to one or more other nodes. In various embodiments, each ledger entry in the data diode ledger indicates whether the node is a permissible node for incoming and / or outgoing data transmission (e.g., by storing an indicator for each node in the ledger that identifies the permissible direction of data transmission). In some examples, the organization also identifies the hierarchical levels associated with the given node and / or with any other node that is allowed to communicate (e.g., whether each node is level 1, level 2, level 3, etc.). For each of the identified nodes from which it can receive or transmit data (e.g., as a start node and / or end node), the organization obtains a node identifier and stores that identifier in the data diode ledger, thereby constructing a table identifying which nodes can transmit data to which other nodes (or which nodes can receive data from which other nodes). It should be noted that although the example embodiments are described herein with regard to nodes as part of a single organization, the techniques disclosed herein can also be used to control directed information flow between nodes across different organizations.

[0033] Regarding the identity ledger 145, the organization obtains long-term signing keys associated with those identifiers and stores these long-term signing keys in a column of the identity ledger configured to store long-term signing keys. The organization also obtains short-term encryption keys associated with those identifiers and stores these short-term encryption keys in a column of the identity ledger configured to store short-term encryption keys. The organization then signs the data diode ledger and the identity ledger using its own private signing key 142. The resulting data diode ledger and identity ledger are considered trustworthy and verifiable because the binding between the individual identifiers and keys is signed with the organization's private signing key and can be verified using a public signing key corresponding to the organization's private signing key (e.g., through each data diode as described in detail below). In this way, signing each ledger with signing key 142 prevents unscrupulous parties (e.g., malicious actors) from providing nodes with tampered ledgers for attempting to launch attacks.

[0034] While the information in the Identity Ledger 145 and / or the Data Diode Ledger 146 is accessible to entities (e.g., the information stored in the Identity Ledger 145 and the Data Diode Ledger 146 is not private), the information stored therein cannot be modified by individual users. In one implementation, the Identity Ledger 145 and the Data Diode Ledger 146 comprise ledger tables in a Microsoft Structured Query Language (SQL) server.

[0035] According to an embodiment, the long-term signature keys collected for the nodes are stored on nodes 102A-102N and / or obtained from nodes 102A-102N. For example, as... Figure 1A As shown, each of nodes 102A-102N stores a corresponding key pair 106A-106N, which includes a long-term private signature key and a long-term public signature key. The long-term signature key pairs 106A-106N are generated by a trusted or client-controlled service. Each key pair of long-term signature key pairs 106A-106N includes randomly generated numbers (e.g., the service includes a random number generator to generate the long-term signature key pairs 106A-106N). According to one embodiment, the service is executed locally on each of nodes 102A-102N. According to another embodiment, the service is executed remotely from nodes 102A-102N. According to such an embodiment, the long-term signature key pairs 106A-106N are generated from a key generation service, wherein nodes 102A-102N submit a request for the long-term key pairs to the service. In response to receiving the request, the service generates (e.g., randomly) the long-term key pairs and provides the generated key pairs to the requesting computing device via a response. According to an embodiment, the service is based on a proof-of-ownership (POP); however, it should be noted that the embodiments described herein are not limited thereto.

[0036] In the example, the long-term private signature key pairs for 106A-106N are stored locally in the secure environment of each node in 102A-102N. Examples of secure environments include, but are not limited to, Trusted Platform Modules (TPMs), Hardware Security Modules (HSMs), or any type of secure hardware and / or software-based cryptographic processors. In other instances, the key pairs may be stored in one or more secure zones coupled to one or more nodes.

[0037] Ledger database 144 is configured to provide nodes 102A-102N with access to identity ledger 145 and data diode ledger 146, which indicate the identities of nodes across an organization and the permitted communications for each node. For example, node 102A may include a first set of data diodes associated with it, then node 102B may include a second set of data diodes, and so on. In an implementation, the diode ledgers for each node in the network can be different from each other because each ledger contains the identities of other nodes that can communicate with a given node. Note that in this embodiment, ledger database 144 is configured to provide nodes with updates to the data diode ledgers, and the permitted communications for a given node may change over time. In this example, each data diode ledger includes a set of data diode ledger entries, each entry identifying another node from which communication can be received and / or to which communication can be transmitted. Therefore, as used herein, a data diode ledger also refers to a set of data diode ledger entries. A given set of data diode ledger entries can be arranged in a single data diode ledger (e.g., a single data diode ledger identifying communications to / from multiple nodes) and / or across multiple data diode ledgers (e.g., one or more data diode ledgers for a given node).

[0038] In various implementations, key pairs 106A-106N also include a public signature key corresponding to signature key 142, enabling each node to use this public signature key to verify that the identity ledger 145 and its associated data diode ledger have not been tampered with. For example, when the identity ledger and each data diode ledger are signed using the management entity's private signature key (e.g., signature key 142), each data diode of each node can verify (e.g., at periodic intervals, using each data transfer, and / or each time a new or updated ledger is obtained) that each ledger is trustworthy by using the public signature key corresponding to the private signature key. In various other implementations, key pairs 106A-106N also include short-term encryption key pairs (e.g., a public short-term encryption key and a private short-term encryption key).

[0039] In an embodiment, data diodes 104A-104N are configured to access the ledger associated with a given node to determine whether communication (e.g., incoming and / or outgoing) is permissible. In an example, node 102A may include only the ledger identifying other nodes to which node 102A may send data. In other words, node 102A may not include the ledger identifying any other node that is permitted to receive information from it. When communication is directed to node 102A, data diode 104A may attempt to locate the node in the appropriate ledger and determine that such communication is not permitted due to the lack of such a ledger. In another example, when transmitting communication from node 102A, data diode 104 may determine whether the intended receiving node exists in the ledger that allows transmission. If the transmission is permitted, data diode 104A may sign and / or encrypt the transmission and provide it to the intended receiving node. If the intended receiving node is not a permitted recipient of information from node 102A, data diode 104A may block the transmission from it. Similar techniques can be used for each node in nodes 102A-102N to ensure that communication between allowed nodes occurs.

[0040] Figure 1B A block diagram of another data diode system 150 according to an example embodiment is shown. In the example, system 150 is an example implementation of system 100. Figure 1B As shown, system 150 includes multiple nodes 102A-102N coupled to one or more networks 148, and a DB host 140. Figure 1B In this example, node 102A is configured to access (remotely or locally) data diode ledger 108. Node 102B is configured to access data diode ledgers 116 and 124. Node 102N is configured to access data diode ledger 132. Each data diode in data diodes 104A-104N accesses the corresponding data diode associated with each node in nodes 102A-102N to determine whether each incoming and / or outgoing data communication is permitted. In this example, each node in nodes 102A-102N also accesses identity ledger 145, such as... Figure 1B As shown.

[0041] In the example, each data diode ledger includes multiple rows and / or columns. Figure 1BIn the illustrated examples, each data diode ledger includes columns identifying the starting node (e.g., the node from which data transmission may originate) and columns identifying the ending node (e.g., the node to which data may be transmitted). For example, data diode ledger 108 includes column 110 identifying the starting node (node ​​102A in this illustration) and column 112 identifying the ending node (e.g., the next node, or another node to which node 102A may transmit data). Data diode ledger 116 includes column 118 identifying the starting node (e.g., the previous node, or another node from which node 102B may receive data) and column 120 identifying the ending node (node ​​102B in this illustration). Data diode ledger 124 includes column 126 identifying the starting node (node ​​102B in this illustration) and column 128 identifying the ending node (e.g., the next node, or another node to which node 102B may transmit data). Data diode ledger 132 includes column 134 identifying the starting node (e.g., a previous node, or another node from which node 102N can receive data) and column 136 identifying the ending node (node ​​102N in this illustration). It should be understood that, although... Figure 1B Each data diode ledger shown includes two columns, but in some examples, a single column can be implemented. For example, for a given node, the data diode ledger may include a single column indicating each node to which a transmission is allowed to be sent. In another example, for a given node, the data diode ledger may include a single column indicating each node to which a transmission is allowed to be sent. In some other implementations, a single ledger may be used to indicate each node to which a transmission is allowed to be sent and each node to which a transmission is allowed to be sent.

[0042] Identity ledger 145 includes column 152 for node identifiers, column 154 for associated long-term signing keys, and column 156 for associated short-term encryption keys. Although identity ledger 145 and data diode ledgers 108, 116, 124, and 132 are shown as separate, any one or more entries contained in these ledgers (and other ledgers described herein but not explicitly shown) may be combined or grouped into a single ledger.

[0043] like Figure 1BAs shown, node 102A does not include any data diode ledger entry indicating that node 102A can receive information (e.g., an entry identifying a previous node), which indicates that communication from other nodes to node 102A is not permitted. Similarly, node 102N does not include any data diode ledger entry indicating that node 102N can transmit information (e.g., an entry identifying the next node), which indicates that communication from node 102N to other nodes is not permitted. Data diodes 104A and 104N are configured to enforce such communication restrictions based on the absence of such ledger entries. In other examples, such as when a given node receives data from another node not listed as the starting node in the associated ledger (e.g., node 102B receives data from a node not identified as the starting node in data diode ledger 116), data diode 104B may indicate that such transmission is not permitted and take any appropriate action (e.g., block the transmission, delete the transmission, notify the administrator or security platform, etc.). Similarly, if node 102B attempts to transmit data to a node not listed as a termination node in the data diode ledger 124, data diode 104B can indicate that the transmission is not permitted and take appropriate measures in response. Such attempted data transmission can be triggered by the actions of a malicious actor or occur due to benign or other unintentional activities (e.g., software problems on the node leading to unintentional transmission of information). In these instances, the transmission can be blocked, thereby preventing the node from receiving information it did not intend to receive. In this way, data diodes 104A-104N can enforce the manner in which communication occurs between nodes, including the direction of such communication.

[0044] It should be understood that the examples illustrated herein are merely illustrative. For instance, a data diode ledger may identify only a single node with which it is permitted to communicate, may identify multiple such nodes, or may identify zero of these nodes. Furthermore, a data diode ledger may include any suitable structure or arrangement. In some implementations, data diode ledgers for the previous node and the next node are combined into a single ledger. In some further implementations, data diode ledgers for multiple different nodes, or even all nodes, are combined into a single ledger. Figure 7BAn example of combined ledger information for multiple nodes is shown. In other implementations, the data diode ledger for each node is separated based on a directional path (e.g., a data diode ledger set identifying the previous node and a data diode ledger set identifying the next node). In other implementations, the data diode ledger for each node is separated based on the node's hierarchy (e.g., a first data diode ledger set for nodes at the same hierarchy as the given node, a second data diode ledger set for nodes at a lower hierarchy than the given node, and / or a third data diode ledger set for nodes at a higher hierarchy than the given node). The advantage of separating the ledgers (e.g., by directional paths and / or by hierarchical levels) is that it makes it possible to implement separate data diodes in separate areas of the computing device (each separate data diode corresponding to a specific data diode ledger set for a given node), thereby further reducing the impact of malicious actors' attempted access (e.g., by reducing side-channel attacks).

[0045] Figure 2 A block diagram depicting another data diode system 200 according to an embodiment is shown. (As...) Figure 2 As shown, system 200 includes example implementations of nodes 102A, 102B, and 102N. Node 102B is associated with example implementations of data diode ledgers 116 and 124. Node 102B also accesses an example implementation of an identity ledger 145. Node 102B includes an example implementation of a data diode 104B. Data diode 104B includes a data decryptor 202, a transmission verifier 204, and a data encryptor 206. Data diode ledgers 116 and / or 124 may be stored locally on node 102B and / or may be stored remotely (e.g., on a server such as DB host 140 or other computing devices). In some implementations, one or more of nodes 102A, 102B, or 102N may be adjacent to each other (e.g., in a single warehouse, facility, building, etc.). In other implementations, one or more of nodes 102A, 102B, or 102N can be located remotely to each other (e.g., as different nodes of an organization located in different geographic regions).

[0046] Although Figure 2 (And other embodiments described herein) are described as examples of node 102B receiving an information set from node 102A and / or transmitting an information set to node 102N, but such examples are not intended to be limiting. Rather, refer to Figure 2The techniques described in the examples are intended to illustrate how data diodes can be implemented on any node and / or within another device (e.g., in a region of a computing device) to control the permissible flow of information between sets of nodes. For example, node 102A and / or node 102N (or any other node not explicitly shown) may contain data diodes similar to data diode 104B and access the corresponding data diode ledger to indicate whether incoming and / or outgoing communication is permissible.

[0047] Data decryptor 202 is configured to receive encrypted data 208 from node 102A and decrypt the received data. In the example, the data transmitted by node 102A is encrypted using an encryption key (e.g., a public encryption key) corresponding to node 102B. Data decryptor 202 uses the private key of node 102B corresponding to the public encryption key to decrypt the incoming data.

[0048] Transmission verifier 204 is configured to determine whether data received from node 102A is authentic. For example, transmission verifier 204 uses a long-term signing key corresponding to node 102A (e.g., obtained from identity ledger 145) to verify whether the digital signature in the received data indicates that the data indeed originated from node 102A (as opposed to a malicious actor or another node). In this example, the transmission verifier then determines whether node 102A (if the transmission did originate from node 102A) is identified as a previous or starting node in data diode ledger 116. If node 102A is identified as a previous node in data diode ledger 116 that can receive communication, then the communication is deemed permissible. If node 102A is not identified as a previous node in data diode ledger 116, the received data is not permissible communication. In this scenario, further transmissions via node 102B are blocked, deleted, and / or prevented.

[0049] Data encryptor 206 is configured to prepare data for transmission to subsequent nodes such as node 102N. In this example, data encryptor 206 signs the data using a signature key associated with node 102B. Data encryptor 206 is also configured to encrypt the data before transmission to node 102N. For example, data encryptor 206 identifies node 102N from a list of nodes in data diode ledger 124, which identifies permissible end nodes or outgoing nodes. Once the intended recipient (i.e., node 102N) is identified, data encryptor 206 obtains a short-term encryption key corresponding to node 102N from identity ledger 145. Data encryptor 206 can then transmit encrypted data 214 (encrypted using node 102N's key) to node 102N, after which node 102N's data diode can perform similar steps with respect to the incoming data.

[0050] In another example, a communication session between two or more nodes (e.g., communication from node 102A to node 102N) can utilize a symmetric encryption key (K). S To encrypt, node 102A can generate the key K. S Using the public key associated with node 102N to configure key K S Encryption is performed, and the encryption key is transmitted to node 102N. Once the encryption key is received, node 102N can use the private key associated with node 102N to generate the decryption key K. S Following this process, subsequent communication between node 102A and node 102N during a given session (or across multiple sessions) can be achieved by utilizing key K. S This is performed to encrypt communications, and in some embodiments, it can provide additional efficiency compared to using public-key encryption.

[0051] In this way, the data diode 104B can determine whether incoming data is allowed to be received and whether outgoing data is allowed to be transmitted. By implementing a virtual diode in this way, the directed transmission of data can be controlled in a desired manner, thereby mitigating the impact of malicious intrusion. Even if a malicious actor attempts to modify a data diode ledger, such an attempt will be prevented because the ledger is maintained in a tamper-proof manner (e.g., in a blockchain), and in the example embodiment, these ledgers cannot be cryptographically corrupted in an undetected manner. According to the technology of this disclosure, tampering with the ledger can be detected, and if such tampering is detected, the tampered ledger can be recovered in various ways (e.g., from a backup copy, recreated by an organization that owns and / or manages the ledger, etc.).

[0052] According to one or more embodiments, data diodes can be implemented in various scenarios to enhance data security. For example, Figure 3 A flowchart 300 is shown illustrating a method for implementing a data diode according to an exemplary embodiment. In an embodiment, flowchart 300 consists of… Figure 1A The system 100 shown Figure 1B The system 150 shown, and / or Figure 2 The system 200 shown is implemented. Therefore, reference will be made to... Figure 1A , Figure 1B ,as well as Figure 2 To describe flowchart 300. Based on the following information about flowchart 300, Figure 1A System 100 Figure 1B System 150, and Figure 2 The discussion of System 200, other structures, and operational embodiments will be obvious to those skilled in the art.

[0053] Flowchart 300 begins at step 302. In step 302, encrypted data transmitted from the first node is received, wherein the data is encrypted using the public key associated with the second node. For example, refer to... Figure 2 Data decryptor 202 is configured to receive encrypted data from node 102A. In the implementation, node 102A uses a data encryptor (e.g., similar to data encryptor 206) to encrypt the data. In the example, the encrypted data received from node 102A is encrypted using a public key associated with node 102B. For example, the public key includes a public encryption key associated with node 102B provided to node 102A (e.g., by node 102B, by DB hose 140, or by another entity).

[0054] In some implementations, node 102A can identify the public key from a ledger (e.g., identity ledger 145). For example, node 102A's data diode 104A can use data diode ledger 108 to identify node 102B as a node permitted to transfer data, and use identity ledger 145 to identify the encryption key corresponding to node 102B (e.g., a short encryption key from column 156). In various embodiments, data diode 104A also signs the data using a signing key known to node 102A (e.g., a public signing key) before transmission. In one example, data diode 104A signs the data before encryption. In another example, data diode 104A encrypts the data before signing.

[0055] In step 304, the encrypted data is decrypted using the private key associated with the second node to generate decrypted data. For example, refer to... Figure 2Data decryptor 202 uses the private key associated with node 102B to decrypt the received encrypted data to generate decrypted data 210. In various embodiments, the private key associated with node 102B includes a private encryption key paired with the public encryption key used by node 102A to encrypt data. By applying the private encryption key and the received encrypted data to a decryption algorithm, data decryptor 202 generates decrypted data.

[0056] In some implementations, if the data received from node 102A is not encrypted, the data diode 104B can be configured to mark the transmission as an unauthorized data transmission. For example, communication between nodes 102A-102N can be designed to be encrypted (e.g., in a high-security environment). In the event that an attacker attempts to compromise a node and / or communication path to transmit data in an unencrypted manner, the data decryptor 202 can automatically determine that the transmission is likely malicious based on the unencrypted information received from node 102A and therefore take one or more preventative measures (e.g., discard the transmission, notify a security entity or platform, etc.). Similarly, if the data decryptor 202 cannot decrypt a received transmission using the key associated with node 102B (e.g., a private key), the data decryptor 202 can similarly determine that the transmission is likely malicious and take one or more preventative measures.

[0057] In step 306, it is determined whether the digital signature in the decrypted data corresponds to an entry of a first node mapped to a first ledger entry set. For example, transmission verifier 204 is configured to receive decrypted data 210 and determine whether the digital signature in the decrypted data corresponds to an entry of a first node mapped to a data diode ledger 116 (which includes a set of ledger entries identifying nodes that allow data transfer). In various embodiments, transmission verifier 204 may determine whether data can be received from a given node based at least in part on orientation information contained in the data diode ledger (e.g., in columns 118 and 120). As described above, in various implementations, node 102A is configured to digitally sign the data transfer using a signature key (e.g., a public signature key) to verify that the transmitted data originates from node 102A. In the example, transmission verifier 204 applies the received signature information and the signature key (e.g., a private signature key obtained from the identity ledger 145 corresponding to node 102A) to a signature verification algorithm to determine whether the digital signature indicates that the transfer was provided by node 102A (in contrast to another entity).

[0058] In implementation, if the transmission verifier fails to identify node 102A as an entity in the identity ledger 145 or fails to verify the digital signature (e.g., the signature key obtained from the identity ledger 145 does not correspond to the received digital signature, or no signature is received), the transmission verifier 204 may determine that the transmission is potentially malicious and take one or more preventative measures, similar to those discussed elsewhere herein. If the transmission verifier 204 uses the identity ledger 145 to determine that the signature does indeed correspond to a given node (e.g., node 102A), the transmission verifier 204 determines whether that node (at least based on the digital signature information) is identified in an entry in the data diode ledger 116. If the node (e.g., node 102A) is not identified as a node permitted for incoming transmissions, the transmission verifier 204 may determine that the transmission is potentially malicious and take one or more preventative measures as described herein. In this way, if data diode 104B receives a transmission of information from a node other than those specifically identified in data diode ledger 116 (e.g., from a malicious entity), such a transmission can be easily identified as malicious and prevented from further transmission.

[0059] In step 308, based on the fact that the digital signature has been determined to correspond to a ledger entry, the first node is verified as a trusted entity. For example, refer to... Figure 2 The transmission verifier 204 determines that node 102A is a trusted entity based on a digital signature that has been identified as corresponding to an entry in the data diode ledger 116. In other words, based on the verification of the digital signature received in a transmission from node 102A and the determination that the signature corresponds to an entry in the tamper-proof data diode ledger 116, it can be confirmed that the transmission was received from node 102A and that node 102A is a node from which transmission is permitted.

[0060] In step 310, based on verification, it is determined that the transmission of encrypted data from the first node is permissible data transmission. For example, refer to... Figure 2 The transmission verifier 204 determines, based on verification, that the transmission of encrypted data received from node 102A is an permitted data transmission. Because node 102A is identified as a node that is permitted to transmit from, and it is also verified that the received transmission was provided by node 102A (e.g., based on a signature), the transmission is identified as an permitted data transmission.

[0061] In this way, every data transmission from one node to another can be managed, allowing only certain types of communication to be permitted (e.g., based on which nodes are allowed to receive data, which nodes are allowed to send data, etc.). Therefore, the techniques of this disclosure not only enable fine-grained identification of which nodes can communicate with each other, but also make it possible in which directions that communication can occur. Such techniques can enhance data security for individual nodes and / or the entire system of nodes, for example by ensuring that confidential and sensitive information is only propagated from lower-security nodes to higher-security nodes. Furthermore, these techniques minimize the ability of malicious actors to infiltrate the node network when attempting to initiate communication. According to embodiments of this disclosure, such attempted communication can be easily identified and / or blocked.

[0062] According to one or more embodiments, information received by one node can then be transmitted to another node. For example, while the preceding examples described instances of a receiving node receiving information from a transmitting node, the techniques described herein can also be implemented to enable a transmitting node to securely transmit information to one or more other nodes. For example, Figure 4 A flowchart 400 of a method for transmitting data to a third node according to an example embodiment is shown. In the embodiment, flowchart 400 is composed of... Figure 1A The system 100 shown Figure 1B The system 150 and / or shown Figure 2 The system 200 shown is implemented accordingly. Therefore, reference will be made to... Figure 1A , Figure 1B ,as well as Figure 2 Describe flowchart 400. Based on the following information about flowchart 400... Figure 1A System 100 Figure 1B System 150, and Figure 2 The discussion of System 200, other structures, and operational embodiments will be obvious to those skilled in the art.

[0063] Flowchart 400 begins at step 402. In step 402, data is encrypted using a public key associated with a third node, which is identified from a second ledger entry set that identifies at least one node to which the second node can securely transmit data. For example, refer to... Figure 2Data encryptor 206 is configured to obtain data 214 and, for example, data to be transmitted to another node, and identify a public key corresponding to the intended recipient of the data. In the example, the intended recipient is one or more nodes identified in the data diode ledger 124 that identify node 102B as capable of securely transmitting data. In various other embodiments, the intended recipient is identified at least based on the determination that node 102B can use information contained in the ledger to transmit outgoing data to the intended recipient. In this way, node 102B can transmit data only to those entities listed in the data diode ledger 124, while preventing data transmission to other nodes not listed as permitted recipients. Upon identifying the intended recipient of the data (i.e., a specific node in the data diode ledger 124), an encryption key corresponding to the intended recipient node is obtained. In an implementation, the encryption key includes a short-term encryption key corresponding to the node in the ledger (e.g., the key in column 156). In another implementation, the encryption key may be obtained from the intended receiving node, from DB host 140, or from another entity.

[0064] In step 404, data encrypted using the public key associated with the third node is transmitted to the third node. For example, refer to... Figure 2 Data encryptor 206 can be configured to transmit data encrypted with a public key to node 102N (or to another node indicating the intended recipient of the data). Upon receiving the encrypted data, a data diode (similar to data diode 104B) on node 102N implements similar techniques as described herein to decrypt the information, verify whether the information was transmitted from node 102B, and verify whether node 102B is identified in the data diode ledger indicating permission for node 102B to transmit information to node 102N. Similar techniques can be implemented across nodes in a network or organization to ensure one-way communication between designated nodes and improve overall security.

[0065] It should be understood that while flowchart 400 illustrates node 102B transmitting data it receives from node 102A (e.g., where node 102B acts as an intermediary), the implementation is not limited to this. Similar techniques can be applied where node 102B is the first sender of data (e.g., data is generated by node 102B or is local to 102B), or node 102B is the first level in a node-level hierarchy. In further implementations, when transmitting information between three or more nodes (e.g., where one or more nodes act as intermediaries), one or more techniques described according to flowchart 400 can be used. In such implementations, additional and / or alternative encryption and / or signature techniques can be used. For example, the data can be encrypted using the encryption key of the node allowed to view the transmitted information (this encryption key can be different from that of the intermediate node if intermediate nodes are not allowed to access the transmitted information). In another example, additional and / or alternative signature protocols can be employed so that the final recipient can verify that the transmitted information originated from a given node and has not been tampered with by any other node during transmission.

[0066] According to one or more embodiments, the virtual data diode described herein can be updated periodically. For example, Figure 5 A flowchart 500 of a method for updating a first set of ledger entries according to an example embodiment is shown. In the embodiment, flowchart 500 is composed of... Figure 1A The system 100 shown Figure 1B The system 150 shown, and / or Figure 2 The system 200 shown is implemented. Therefore, reference will be made to... Figure 1A , Figure 1B as well as Figure 2 Describe flowchart 500. Based on the following information about flowchart 500... Figure 1A System 100 Figure 1B System 150, and Figure 2 The discussion of System 200, other structures, and operational embodiments will be obvious to those skilled in the art.

[0067] Flowchart 500 begins at step 502. In step 502, an update to the first ledger entry set is received from the management entity, the update including at least one of adding or removing nodes from the node list. For example, refer to... Figure 1BDB host 140 can update one or more ledgers in identity ledger 145 and / or data diode ledger 146. Updates may include any change to information stored in the corresponding data diode ledger on any node, including but not limited to: adding a node, removing a node, changing a long-term signing key, changing a short-term encryption key, adding or removing a ledger, or any other change. In implementations, updates are performed in a tamper-proof manner (e.g., using blockchain technology). In various embodiments, DB host 140 signs the updated ledger(s) using signing key 142.

[0068] Once updated data diode ledgers are generated, DB host 140 transmits the data diode ledgers (or otherwise makes these ledgers available) to each node coupled to the network 148. When a particular node receives an updated ledger, the data diode within that node can verify that the updated ledger is authentic (i.e., it is signed by signing key 142) and, according to the techniques of this disclosure, use the information contained in the updated data diode ledger to identify whether communication to and / or from that node is permissible. For example, if node 102B receives updates to data diode ledgers 116 and / or 124 to add or remove nodes from the list of nodes contained therein, data diode 104B can be configured to manage incoming and / or outgoing communication to node 102B based on the addition and / or removal of nodes. In this manner, data diodes can be updated by updating the corresponding data diode ledger, which is superior to other techniques where physical data diodes require physical reconfiguration, addition, removal, or otherwise rewiring (e.g., physical data diode devices using optical sensors or air gaps). Embodiments of this disclosure enable more efficient modification of virtual data diodes, thereby allowing for faster changes to data control (which can impact data security and the utilization of computing resources).

[0069] In the examples, the data diodes described herein can be implemented in various ways and / or in various types of hardware devices. For example, Figure 6 A flowchart 600 of a method for performing a data diode operation in a region is shown according to an example embodiment. In the embodiment, flowchart 600 is composed of... Figure 1A The system 100 shown Figure 1B The system 150 shown Figure 2 The system 200 and / or shown Figure 7A The system 700 shown is implemented as described. Therefore, reference will be made to... Figure 1A , Figure 1B ,as well as Figure 2 Describe flowchart 600. Therefore, refer to... Figure 1A 1B Figure 2 ,as well as Figure 7A Describe the flowchart 600. Figure 7A A block diagram of a data diode system 700 operating in a region according to an example embodiment is shown. Figure 7A As shown, system 700 includes computing device 702, data diode ledger set 712, data diode ledger set 714, node 716, and node 718. Computing device 702 includes region 704 and region 708. Region 704 includes data diode 706. Region 708 includes data diode 710. Nodes 716 and 718 are examples of nodes 102A-102N. Data diodes 706 and 710 are examples of data diodes 104A-104N. Data diode ledgers 712 and 714 are examples of data diode ledgers 108, 116, 124, and / or 132. Although not shown, according to the technology of this disclosure, each data diode in data diodes 706 and 710 can access identity ledger 145.

[0070] According to one embodiment, regions 704 and 708 are implemented in separate security regions of hardware computing device 702. According to another embodiment, regions 704 and 708 are implemented in a separate computing device. According to yet another embodiment, computing device 702 includes a plurality of additional security regions (not shown), each additional security region including a data diode for controlling communication flow between a plurality of additional nodes (not shown). Based on the following regarding flowchart 600, Figure 1A System 100 Figure 1B System 150 Figure 2 System 200, and Figure 7A The discussion of System 700, other structural and operational embodiments will be obvious to those skilled in the art.

[0071] Flowchart 600 begins at step 602. In step 602, the data diode is executed within a secure area of ​​the computing device, wherein the computing device comprises multiple secure areas isolated from each other. For example, refer to... Figure 7AData diode 706 is executed in region 704, and data diode 710 is executed in region 708. Both regions 704 and 708 comprise secure regions of the hardware computing device 702. In implementations, regions 704 and 708 are isolated from each other. For example, region 704 includes an operating environment (e.g., operating system, applications, etc.) that is not shared with region 708, and vice versa. In some implementations, region 704 may utilize common resources of the computing device 702, such as processors, memory, etc. However, each region is isolated from every other region of the computing device 702, such that actions performed in one region (e.g., data transfer, processes, application execution, etc.) are not visible or accessible in another region. In other words, in various embodiments, regions of the computing device 702 cannot directly communicate with each other or otherwise transfer data. In this way, a single computing device may include several different operating environments, each of which is securely isolated from each other (e.g., by preventing lateral movement or side-channel attacks).

[0072] In the example embodiment, all network communication between communicating nodes can be controlled by one or more entities implementing the techniques described herein (e.g., based on program code, etc.), causing network communication flows through appropriate data diodes. For example, zone 704 is implemented to intercept all network traffic from node 716, and zone 708 is implemented to intercept all network traffic from node 718. Similarly, zone 708 is implemented to intercept all network traffic destined for node 716 (e.g., from any other node), and zone 704 is implemented to intercept all network traffic destined for node 718. In the example, this configuration ensures that malicious actors attempting to infiltrate the network cannot bypass the data diodes implemented in each secure zone. To this end, in various implementations, zones 704 and 708 are configured to securely maintain (physically, via software devices or other devices) the executable code within each zone (e.g., data diodes 706 and 708) in a tamper-proof and comprehensive manner. By preventing the code in each region from being tampered with, each data diode can operate without interruption and / or alteration to intercept communication between nodes and ensure that data flows only in permitted ways.

[0073] In some implementations, zones 704 and 708 may include virtual machines executing on computing device 702. In some other implementations, zones 704 and 708 may utilize certain hardware separate from each other (e.g., different hardware processing units, different memory devices, different allocations of the same memory, etc.). In some other examples, zones may be implemented as a combination of software and / or hardware. An example of a zone described herein is the Intel® Software Protection Extension. In some implementations, each zone is protected against external attacks, such as physical attacks (e.g., those caused by physical intrusion) and / or electronic attacks (e.g., those caused by malicious communication to the zone). Computing device 702 may include any suitable hardware for executing each zone therein. In some embodiments, computing device 702 includes server devices, such as servers co-located with one or more nodes of the network described herein. In some other embodiments, multiple computing devices 702 are provided, each executing multiple zones to control the flow of communication between certain nodes. In some implementations, each zone is pre-programmed to execute code in a way that cannot be altered (e.g., except by an administrator). Therefore, the data diodes that operate with each region cannot be interfered with (e.g., by an unfavorable party), thus further enhancing security.

[0074] In the example, regions 704 and 708 are each configured for directed data transfer between control node sets (e.g., locally on computing device 702). For example, as... Figure 7A As shown, data diode 706 in region 704 is configured to control the directional transmission of data from node 716 to node 718. Similarly, data diode 710 in region 708 is configured to control the directional transmission of data from node 718 to node 716. For example, data diode ledger 712 can indicate that node 716 can transmit data to node 718 (e.g., in the forward direction), but node 718 cannot transmit data to node 716 (e.g., in the reverse direction). Therefore, according to the techniques described herein, data diode 706 can ensure that data communication from node 716 flows only in a single direction (i.e., in the forward direction), while preventing communication in the reverse direction. Conversely, data diode ledger 714 can indicate that node 718 can transmit data to node 716, but node 716 cannot transmit data to node 718. According to the techniques of this disclosure, using data diode ledger 714, data diode 710 can ensure that communication flows from node 718 to node 716, and not vice versa.

[0075] By implementing such for each communication path Figure 7AThe separate data diodes shown (e.g., one data diode for forward communication and another for reverse communication) can separate the forward and reverse communication paths. Therefore, even if a malicious entity can disrupt a secure area controlling communication in one direction (e.g., area 704), such disruption will not allow the malicious entity to access another area to inject or intercept communication in the other direction.

[0076] It should be understood that any number of nodes and / or regions can exist in the implementation to control data transfer between them. For example, each region can control data transfer in a directed manner between multiple incoming nodes and / or multiple outgoing nodes (e.g., by utilizing a suitable data diode ledger for each such node to be managed). Furthermore, the computing device 702 itself may include nodes from the node set. In other words, in some implementations, one or more regions (including data diodes) may be implemented within a node (e.g., within node 102B as described above). In other implementations, the computing device 702 may be arranged as a hardware device between two other nodes (e.g., as an intermediary).

[0077] Figure 7B An exemplary data diode ledger is shown according to an example embodiment. Figure 7B The diagram illustrates a illustrative data diode ledger 720, which includes multiple rows and columns. (Example:) Figure 7B As shown, the data diode ledger 720 includes a column 722 for data diode identifiers (IDs), a column 724 for start nodes, and a column 726 for end nodes. The data diode ledger 720 can be used as a data diode ledger for multiple data diodes (e.g., data diodes implemented in a region as previously described, or any other data diodes described herein). Each row of the data diode ledger 720 can indicate a specific permitted communication flow (e.g., direction) between node pairs. The data diode ledger 720 is intended to illustrate one way of arranging data diode information in a ledger, and is not intended to be restrictive. According to the techniques of this disclosure, any number of diodes, nodes, etc., can be specified in the data diode ledger 720, and the data diode ledger 720 can contain more than Figure 7B Additional (or less) information is shown. III. Example Mobile Device and Computer System Implementations

[0078] As indicated herein, the described embodiments, together with any of their circuitry, components and / or sub-components, and the flowcharts / flowcharts (including portions thereof) and / or other embodiments described herein, can be implemented in hardware, or hardware having any combination of software and / or firmware, including computer program code (program instructions) implemented as configured to execute in one or more processors and stored in a computer-readable storage medium, or implemented as hardware logic / circuit, such as in a system-on-a-chip (SoC), field-programmable gate array (FPGA), and / or application-specific integrated circuit (ASIC). An SoC may include an integrated circuit chip that includes one or more processors (e.g., microcontrollers, microprocessors, digital signal processors (DSPs), etc.), memory, one or more communication interfaces, and / or other circuitry and / or embedded firmware that perform its functions.

[0079] The embodiments disclosed herein can be implemented in one or more computing devices, which can be mobile (mobile devices) and / or fixed (fixed devices), and can include any combination of features of such mobile and fixed computing devices. Examples of computing devices in which the embodiments can be implemented are provided below. Figure 8 The description is as follows. Figure 8 A block diagram of an exemplary computing environment 800 including computing device 802 is shown. Computing device 802 is an example of nodes 102A-102N, DB host 140, computing device 702, node 716, and / or node 718, which may include one or more components of computing device 802. In some embodiments, computing device 802 is connected to devices outside the computing environment 800 via network 804. Figure 8 (Not shown in the image) is communicatively coupled. Network 804 includes one or more networks such as a local area network (LAN), a wide area network (WAN), an enterprise network, the Internet, etc., and may include one or more wired and / or wireless components. Network 804 may additionally or alternatively include a cellular network for cellular communication. Computing device 802 is described in detail below.

[0080] The computing device 802 can be any of various types of computing devices. For example, the computing device 802 can be a mobile computing device, such as a handheld computer (e.g., a personal digital assistant (PDA)), a laptop computer, or a tablet computer (such as an Apple iPad). TM Hybrid devices, laptops (e.g., Google Chromebook from Google LLC) TMNetbooks, mobile phones (e.g., cellular phones, such as Apple Inc.'s Apple System iPhone® smartphones, implementing Google System Android), and other mobile devices. TM (e.g., phones with Google® operating system), wearable computing devices (e.g., including Google System Glass) TM Smart glasses (head-mounted augmented reality and / or virtual reality devices, such as Oculus Rift® from Facebook, LLC), or other types of mobile computing devices. Alternatively, computing device 802 may be a fixed computing device such as a desktop computer, personal computer (PC), fixed server equipment, minicomputer, mainframe, supercomputer, etc.

[0081] like Figure 8 As shown, computing device 802 includes various hardware and software components, including a processor 810, storage device 820, one or more input devices 830, one or more output devices 850, one or more wireless modems 860, one or more wired interfaces 880, power supply 882, location information (LI) receiver 884, and accelerometer 886. Storage device 820 includes memory 856 and storage device 890, with memory 856 including non-removable memory 822 and removable memory 824. Storage device 820 also stores operating system 812, applications 814, and application data 816. Multiple wireless modems 860 include Wi-Fi modem 862, Bluetooth modem 864, and cellular modem 866. Multiple output devices 850 include speakers 852 and a display 854. Multiple input devices 830 include a touchscreen 832, microphone 834, camera 836, physical keyboard 838, and trackball 840. Figure 8 All components of the computing device 802 shown are present in all embodiments, and additional components not shown may be present, and any combination of these components may be present in a particular embodiment. These components of the computing device 802 are described below.

[0082] A single processor 810 (e.g., a central processing unit (CPU), microcontroller, microprocessor, signal processor, ASIC (Application-Specific Integrated Circuit), and / or other physical hardware processor circuitry) or multiple processors 810 may exist in the computing device 802 for performing tasks such as program execution, signal encoding, data processing, input / output processing, power control, and / or other functions. The processor 810 may be a single-core or multi-core processor, and each processor core may be single-threaded or multi-threaded (to provide multiple execution threads simultaneously). The processor 810 is configured to execute program code stored in a computer-readable medium, such as operating system 812 stored in storage device 820, and program code of application program 814. The program code is constructed to cause the processor 810 to perform operations, including the procedures / methods disclosed herein. The operating system 812 controls the allocation and use of components of the computing device 802 and provides support for one or more application programs 814 (also referred to as "applications" or "apps"). Application 814 may include general computing applications (e.g., email applications, calendars, contact managers, web browsers, messaging applications), other computing applications (e.g., word processing applications, mapping applications, media player applications, productivity suite applications), one or more machine learning (ML) models, and applications related to embodiments disclosed elsewhere herein.

[0083] Any component in computing device 802 can communicate with any other component according to its function, although not all connections are shown for ease of illustration. For example, such as Figure 8 As shown, bus 806 is a multi-signal-line communication medium (e.g., conductive traces in silicon, metal traces along a motherboard, wires, etc.) that can exist to communicatively couple processor 810 to various other components of computing device 802, although in other embodiments, alternative buses, other buses, and / or one or more individual signal lines communicatively couple components. Bus 806 represents any one or more of several types of bus architectures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and any processor or local bus using various bus architectures.

[0084] Storage device 820 is a physical storage comprising one or both of memory 856 and storage device 890, which stores operating system 812, application program 814, and application data 816 according to any distribution. Non-removable memory 822 includes one or more of RAM (Random Access Memory), ROM (Read Only Memory), flash memory, solid-state drive (SSD), hard disk drive (e.g., a disk drive for reading from and writing to a hard disk), and / or other physical storage device types. Non-removable memory 822 may include main memory and may be separate from processor 810 or fabricated in the same integrated circuit as processor 810. Figure 8 As shown, non-removable memory 822 stores firmware 818, which may be present to provide low-level control of the hardware. Examples of firmware 818 include BIOS (Basic Input / Output System, such as in a personal computer) and boot firmware (e.g., in a smartphone). Removable memory 824 may be inserted into a socket of computing device 802 or otherwise coupled to computing device 802 and may be removed by a user from computing device 802. Removable memory 824 may include any suitable type of removable memory device, including SD (Secure Digital) cards, Subscriber Identity Module (SIM) cards well-known in GSM (Global System for Mobile Communications) communication systems, and / or other types of removable physical memory devices. One or more of storage devices 890 may be present inside and / or outside the housing of computing device 802 and may or may not be removable. Examples of storage devices 890 include hard disk drives, SSDs, thumb drives (e.g., USB (Universal Serial Bus) flash drives), or other physical storage devices.

[0085] One or more programs may be stored in storage device 820. Such programs include operating system 812, one or more application programs 814, and other program modules and program data. Examples of such application programs may include, for example, computer program logic (e.g., computer program code / instructions) for implementing one or more of data diodes 104A-104N, ledger database 144, data decryptor 202, transmission verifier 204, data encryptor 206, area 704, data diode 706, area 708 and / or data diode 710, and any of its components and / or subcomponents, and any other features illustrated and / or described herein, including portions thereof, and / or other examples described herein.

[0086] Storage device 820 also stores data used and / or generated by operating system 812 and application 814 as application data 816. Examples of application data 816 include web pages, text, images, tables, sound files, video data, and other data, which may be sent to and / or received from one or more network servers or other devices via one or more wired or wireless networks. Storage device 820 may be used to store other data including user identifiers such as International Mobile Subscriber Identity (IMSI) and device identifiers such as International Mobile Equipment Identity (IMEI). Such identifiers may be transmitted to network servers to identify users and devices.

[0087] Users can input commands and information into computing device 802 through one or more input devices 830, and receive information from computing device 802 through one or more output devices 850. The input devices 830 may include one or more of a touchscreen 832, microphone 834, camera 836, physical keyboard 838, and / or trackball 840, and the output devices 850 may include one or more of a speaker 852 and display 854. Each of the input devices 830 and output devices 850 may be integrated into computing device 802 (e.g., built into the housing of computing device 802) or external to computing device 802 (e.g., wired or wirelessly coupled to computing device 802 via wired interfaces 880 and / or wireless modems 860). Additional input devices 830 (not shown) may include natural user interfaces (NUIs), pointing devices (computer mice), joysticks, video game controllers, scanners, touchpads, styluses, voice identification systems for receiving voice input, gesture identification systems for receiving gesture input, etc. Other possible output devices (not shown) may include piezoelectric or other haptic output devices. Some devices may provide more than one input / output function. For example, a display 854 may display information and operate as a touchscreen 832 as a user interface by receiving user commands and / or other information (e.g., via touch, finger gestures, virtual keyboards, etc.). Any number of each type of input device(s) 830 and output device(s) 850 may be present, including multiple microphones 834, multiple cameras 836, multiple speakers 852, and / or multiple displays 854.

[0088] One or more wireless modems 860 may be coupled to one or more antennas (not shown) of computing device 802 and may support bidirectional communication between processor 810 and devices external to computing device 802 via network 804, as understood by those skilled in the art. Wireless modems 860 are generally shown and may include cellular modems 866 for communicating with one or more cellular networks, such as GSM networks for data and voice communication within a single cellular network, between cellular networks, or between mobile devices and the Public Switched Telephone Network (PSTN). Wireless modems 860 may also, or alternatively, include other radio-based modem types, such as Bluetooth modem 864 (also referred to as a “Bluetooth device”) and / or Wi-Fi modem 862 (also referred to as a “wireless adapter”). Wi-Fi modem 862 is configured to communicate with access points or other wirelessly-enabled remote devices according to one or more wireless network protocols based on the IEEE (Institute of Electrical and Electronics Engineers) 802.11 series of standards, which are commonly used for local area networking and internet access of devices. The Bluetooth modem 864 is configured to communicate with Bluetooth-enabled devices in accordance with multiple Bluetooth short-range wireless technology standards such as IEEE 802.15.1 and / or managed by the Bluetooth Special Interest Group (SIG).

[0089] The computing device 802 may also include a power supply 882, an L1 receiver 884, an accelerometer 886, and / or one or more wired interfaces 880. Example wired interfaces 880 include USB ports, IEEE 1394 (FireWire) ports, RS-232 ports, HDMI (High-Definition Multimedia Interface) ports (e.g., for connection to an external display), display ports (e.g., for connection to an external display), audio ports, Ethernet ports, and / or Apple's Lightning® ports, each of which is well known to those skilled in the art. The wired interfaces 880 of the computing device 802 provide wired connections between the computing device 802 and a network 804, or wired connections between the computing device 802 and one or more devices / peripherals (e.g., point devices, displays 854, speakers 852, cameras 836, physical keyboards 838, etc.) when the computing device 802 is external to these devices / peripherals. Power supply 882 is configured to supply power to each component of computing device 802 and may receive power from a battery inside computing device 802 and / or from a power cord plugged into a power port (e.g., USB port, A / C power port) of computing device 802. L1 receiver 884 may be used for location determination of computing device 802 and may include a satellite navigation receiver such as a Global Positioning System (GPS) receiver, or may include other types of location determiners configured to determine the location of computing device 802 based on received information (e.g., using cell tower triangulation, etc.). Accelerometer 886 may be present to determine the orientation of computing device 802.

[0090] Note that the components illustrated in the computing device 802 are not all necessary or included, and as those skilled in the art will recognize, fewer or more components may be present. For example, the computing device 802 may also include one or more of a gyroscope, barometer, proximity sensor, ambient light sensor, digital compass, etc. The processor 810 and memory 856 may coexist in the same semiconductor device package, such as being included together in an integrated circuit chip, FPGA, or system-on-a-chip (SoC), optionally along with other components of the computing device 802.

[0091] In each embodiment, computing device 802 is configured to implement any of the features described above in the flowcharts herein. Computer program logic for performing any of the operations, steps, and / or functions described herein may be stored in storage device 820 and executed by processor 810.

[0092] In some embodiments, server infrastructure 870 may reside within computing environment 800 and may be communicatively coupled to computing device 802 via network 804. When present, server infrastructure 870 may be a network-accessible set of servers (e.g., a cloud-based environment or platform). Figure 8 As shown, server infrastructure 870 includes clusters 872. Each cluster 872 may include a group of one or more compute nodes and / or a group of one or more storage nodes. For example, as Figure 8 As shown, cluster 872 includes nodes 874. Each node of 874 can be accessed via network 804 (e.g., in a "cloud-based" embodiment) to build, deploy, and manage applications and services. Any node of 874 can be a storage node comprising multiple physical storage disks, SSDs, and / or other physical storage devices that can be accessed via network 804 and configured to store data associated with applications and services managed by node 874. For example, as Figure 8 As shown, node 874 can store application data 878.

[0093] As computing nodes, each node in node 874 may include one or more server computers, server systems, and / or computing devices. For example, node 874 may include one or more components of the computing device 802 disclosed herein. Each node of node 874 may be configured to execute one or more software applications (or "applications") and / or service and / or manage hardware resources (e.g., processors, memory, etc.) that can be utilized by users (e.g., clients) of a network-accessible server group. For example, as Figure 8 As shown, node 874 can operate application 876. In one implementation, a node in node 874 can operate on or include one or more virtual machines, each virtual machine emulating in an isolated manner a system architecture (e.g., an operating system) on which applications such as application 876 can execute.

[0094] In one embodiment, one or more clusters of cluster 872 may coexist in one location (e.g., housed in one or more nearby buildings with associated components such as backup power, redundant data communications, and environmental controls) to form a data center, or may be otherwise arranged. Therefore, in this embodiment, one or more clusters of cluster 872 may be a data center of a distributed collection of data centers. In this embodiment, exemplary computing environment 800 includes portions of cloud-based platforms such as Amazon Web Services® from Amazon Web Services or Google Cloud Platform™ from Google LLC, but these are merely examples and not intended to be limiting.

[0095] In this embodiment, computing device 802 may access application 876 to execute in any manner, such as through a client application and / or browser at computing device 802. Example browsers include: Microsoft Edge® from Microsoft Corporation, Redmond, Washington; Mozilla Firefox® from Mozilla Inc., Mountain View, California; Safari® from Apple Inc., Cupertino, California; and Google® Chrome from Google LLC, Mountain View, California.

[0096] For network (e.g., cloud) backup and data security purposes, computing device 802 may additionally and / or alternatively synchronize copies of application 814 and / or application data 816 to be stored as application 876 and / or application data 878 at a network-based server infrastructure 870. For example, operating system 812 and / or application 814 may include file hosting service clients such as Microsoft® OneDrive®, Amazon Web Services (Amazon S3®), Dropbox®, Google Drive™, etc., configured to synchronize applications and / or data stored on storage device 820 at a network-based server infrastructure 870.

[0097] In some embodiments, a local server 892 may reside within a computing environment 800 and may be communicatively coupled to a computing device 802 via a network 804. When a local server 892 is present, it is hosted within the organization's infrastructure and, in many cases, physically hosted on-site within the organization's facilities. The local server 892 is controlled, managed, and maintained by the organization's IT (information technology) personnel or IT partners. Application data 898 may be shared by the local server 892 among the organization's computing devices, including computing device 802 (when it is part of the organization), via the organization's local network and / or other networks accessible to the organization, including the Internet. Furthermore, the local server 892 may provide applications, such as application 896, to the organization's computing devices, including computing device 802. Therefore, the local server 892 may include a storage device 894 (which includes one or more physical storage devices such as disks and / or SSDs) for storing application 896 and application data 898, and may include one or more processors for executing application 896. In addition, computing device 802 can be configured to synchronize copies of application 814 and / or application data 816 so as to be stored at local server 892 as backups of application 896 and / or application data 898.

[0098] The embodiments described herein can be implemented in one or more of computing device 802, network-based server infrastructure 870, and local server 892. For example, in some embodiments, computing device 802 can be used to implement the systems, clients, or devices, or components / subcomponents thereof, disclosed elsewhere herein. In other embodiments, a combination of computing device 802, network-based server infrastructure 870, and / or local server 892 can be used to implement the systems, clients, or devices, or components / subcomponents thereof, disclosed elsewhere herein.

[0099] As used herein, the terms “computer program medium,” “computer-readable medium,” and “computer-readable storage medium,” etc., are used to refer to physical hardware media. Examples of such physical hardware media include any hard disk, optical disk, SSD, such as RAM, ROM, flash memory, digital video disk, zip disk, MEM (microelectronic machine) memory, other physical hardware media of nanotechnology-based storage devices, and other types of physical / tangible hardware storage media of storage device 820. Such computer-readable media and / or storage media are distinct from and do not overlap with communication media and propagation signals (excluding communication media and propagation signals). Communication media include computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves. The term “modulated data signal” refers to a signal whose one or more characteristics are set or altered in a manner that encodes information in the signal. By way of example and not limitation, communication media include wireless media, such as acoustic, RF, infrared, and other wireless media, as well as wired media. Embodiments also relate to such communication media that are separate from and do not overlap with embodiments relating to computer-readable storage media.

[0100] As described above, computer programs and modules (including application program 814) can be stored in storage device 820. Such computer programs can also be received via network 804 through wired interface(s) 880 and / or wireless modems(s) 860. When executed or loaded by the application program, such computer programs enable computing device 802 to implement the features of the embodiments discussed herein. Therefore, such computer programs represent the controller of computing device 802. The embodiments also relate to computer program products including computer code or instructions stored on any computer-readable medium or computer-readable storage medium. Such computer program products include physical memory of storage device 820 and other types of physical memory. IV. Additional Example Implementations

[0101] This document discloses a data diode system. The system includes: a processor; and a memory device storing program code configured to cause the processor to: receive encrypted data transmitted from a first node, the data being encrypted using a public key associated with a second node; decrypt the encrypted data using a private key associated with the second node to generate decrypted data; determine whether a digital signature in the decrypted data corresponds to a ledger entry of the first node mapped to a first set of ledger entries; verify that the first node is a trusted entity based on the determination that the digital signature corresponds to a ledger entry; and determine, based on the verification, that the transmission of the encrypted data from the first node is an permissible data transmission.

[0102] In one implementation of the aforementioned system, the first set of ledger entries is implemented in a tamper-proof ledger.

[0103] In another implementation of the aforementioned system, the first ledger entry set is signed using a signature key associated with the management entity, and the program code is also configured to enable the processor to verify that the first ledger entry set is trustworthy based on the signature key.

[0104] In another implementation of the aforementioned system, the program code is further configured to cause the processor to: encrypt data using a public key associated with a third node, the public key associated with the third node being identified from a second ledger entry set, the second ledger entry set identifying at least one node to which the second node can securely transmit data; and transmit the data encrypted using the public key associated with the third node to the third node.

[0105] In another implementation of the aforementioned system, the program code is executed in a secure zone of a computing device, which comprises multiple secure zones isolated from each other.

[0106] In another implementation of the aforementioned system, each security zone of the computing device controls the directed transmission of data between local node sets of the computing device.

[0107] In another implementation of the aforementioned system, the program code is further configured to cause the processor to: receive updates to the first set of ledger entries from the management entity, the updates including at least one of adding or removing nodes from the node list.

[0108] This document discloses a method. The method includes: receiving encrypted data transmitted from a first node, the data being encrypted using a public key associated with a second node; decrypting the encrypted data using a private key associated with the second node to generate decrypted data; determining whether a digital signature in the decrypted data corresponds to a ledger entry of the first node mapped to a first ledger entry set; verifying that the first node is a trusted entity based on the determination that the digital signature corresponds to a ledger entry; and determining, based on the verification, that the transmission of the encrypted data from the first node is an permissible data transmission.

[0109] In one implementation of the aforementioned method, the first set of ledger entries is implemented in a tamper-proof ledger.

[0110] In another implementation of the aforementioned method, the first ledger entry set is signed using a signature key associated with the management entity, and the method further includes: verifying that the first ledger entry set is trustworthy based on the signature key.

[0111] In another implementation of the aforementioned method, the method further includes: encrypting data using a public key associated with a third node, the public key associated with the third node being identified from a second ledger entry set, the second ledger entry set identifying at least one node to which the second node can securely transmit data; and transmitting the data encrypted using the public key associated with the third node to the third node.

[0112] In another implementation of the aforementioned method, the method is executed within a secure region of a computing device, which comprises multiple secure regions isolated from each other.

[0113] In another implementation of the aforementioned method, each security zone of the computing device controls the directed transmission of data between local node sets of the computing device.

[0114] In another implementation of the aforementioned method, the method further includes: receiving an update to the first ledger entry set from a management entity, the update including at least one of adding or removing nodes from the node list.

[0115] This document discloses a computer-readable storage medium. The computer-readable storage medium has computer program code recorded thereon, which, when executed by at least one processor, causes at least one processor to perform a method comprising: receiving encrypted data transmitted from a first node, the data being encrypted using a public key associated with a second node; decrypting the encrypted data using a private key associated with the second node to generate decrypted data; determining whether a digital signature in the decrypted data corresponds to a ledger entry of the first node mapped to a first set of ledger entries; verifying that the first node is a trusted entity based on the determination that the digital signature corresponds to a ledger entry; and determining, based on the verification, that the transmission of the encrypted data from the first node is an permissible data transmission.

[0116] In one implementation of the aforementioned computer-readable storage medium, the first ledger entry set is implemented in a tamper-proof ledger.

[0117] In another implementation of the aforementioned computer-readable storage medium, the first ledger entry set is signed using a signature key associated with the management entity, and the method further includes: verifying that the first ledger entry set is trustworthy based on the signature key.

[0118] In another implementation of the aforementioned computer-readable storage medium, the method further includes: encrypting data using a public key associated with a third node, the public key associated with the third node being identified from a second ledger entry set, the second ledger entry set identifying at least one node to which the second node can securely transmit data; and transmitting the data encrypted using the public key associated with the third node to the third node.

[0119] In another implementation of the aforementioned computer-readable storage medium, the method is executed within a secure region of a computing device, which includes multiple secure regions isolated from each other.

[0120] In another implementation of the aforementioned computer-readable storage medium, each secure region of the computing device controls the directed transmission of data between local sets of nodes on the computing device. V. Conclusion

[0121] References to "an embodiment," "embodiment," "example embodiment," etc., in the specification indicate that the described embodiment may include a specific feature, structure, or characteristic; however, each embodiment may not necessarily include that specific feature, structure, or characteristic. Furthermore, these phrases do not necessarily refer to the same embodiment. Moreover, when a specific feature, structure, or characteristic is described in connection with an embodiment, it should be understood that, whether explicitly described or not, such feature, structure, or characteristic can be implemented in combination with other embodiments to the knowledge of those skilled in the art.

[0122] In this discussion, unless otherwise stated, adjectives (e.g., “substantially” and “approximately”) modifying one or more features of embodiments of this disclosure are to be understood as limiting the condition or feature to an operational tolerance acceptable for the embodiments to which it is intended to be applied. Furthermore, where “based on” is used to indicate an effect resulting from the indicated cause, it should be understood that the effect is not required to be produced solely by the indicated cause, but any number of possible additional causes may also contribute to the effect. Therefore, as used herein, the term “based on” should be understood to be equivalent to the term “at least based on”.

[0123] While various embodiments of this disclosure have been described above, it should be understood that they are presented merely as examples and not as limitations. Those skilled in the art will understand that various changes in form and detail may be made without departing from the spirit and scope of the embodiments as defined in the appended claims. Therefore, the breadth and scope of the claimed embodiments should not be limited to any of the foregoing exemplary embodiments, but should be defined solely by the appended claims and their equivalents.

Claims

1. A data diode system, comprising: processor; as well as A memory device storing program code configured to cause the processor to: Receive encrypted data transmitted from a first node, the data being encrypted using a public key associated with a second node; The encrypted data is decrypted using the private key associated with the second node to generate decrypted data; Determine whether the digital signature in the decrypted data corresponds to a ledger entry mapped to the first node in the first ledger entry set; Based on the fact that the digital signature has been determined to correspond to the ledger entry, the first node is verified to be a trusted entity; as well as Based on the verification, it is determined that the transmission of the encrypted data from the first node is an allowed data transmission.

2. The system of claim 1, wherein the first ledger entry set is implemented in a tamper-proof ledger.

3. The system of claim 2, wherein the first ledger entry set is signed using a signature key associated with the management entity, and The program code is also configured to enable the processor to verify that the first set of ledger entries is trustworthy based on the signature key.

4. The system of claim 1, wherein the program code is further configured to cause the processor to: The data is encrypted using a public key associated with a third node, the public key being identified from a second ledger entry set that identifies at least one node to which the second node can securely transmit data; and The data, which is encrypted using the public key associated with the third node, is transmitted to the third node.

5. The system of claim 1, wherein the program code is executed in a secure area of ​​a computing device, the computing device comprising a plurality of secure areas isolated from each other.

6. The system of claim 5, wherein each security zone of the computing device controls the directed transmission of data between the local set of nodes of the computing device.

7. The system of claim 3, wherein the program code is further configured to cause the processor to: The management entity receives updates to the first set of ledger entries, the updates including at least one of adding or removing nodes from the node list.

8. A method comprising: Receive encrypted data transmitted from a first node, the data being encrypted using a public key associated with a second node; The encrypted data is decrypted using the private key associated with the second node to generate decrypted data; Determine whether the digital signature in the decrypted data corresponds to a ledger entry mapped to the first node in the first ledger entry set; Based on the fact that the digital signature has been determined to correspond to the ledger entry, the first node is verified to be a trusted entity; as well as Based on the verification, it is determined that the transmission of the encrypted data from the first node is an allowed data transmission.

9. The method of claim 8, wherein the first set of ledger entries is implemented in a tamper-proof ledger.

10. The method of claim 9, wherein the first set of ledger entries is signed using a signature key associated with the management entity, and The method further includes: Based on the signature key, the first ledger entry set is verified to be trustworthy.

11. The method of claim 8, further comprising: The data is encrypted using a public key associated with a third node, the public key associated with the third node being identified from a second ledger entry set, the second ledger entry set identifying at least one node to which the second node can securely transmit data; as well as The data, which is encrypted using the public key associated with the third node, is transmitted to the third node.

12. The method of claim 8, wherein the method is performed in a secure area of ​​a computing device, the computing device comprising a plurality of secure areas isolated from each other.

13. The method of claim 12, wherein each security zone of the computing device controls the directed transmission of data between the local set of nodes of the computing device.

14. The method of claim 10, further comprising: The management entity receives updates to the first set of ledger entries, the updates including at least one of adding or removing nodes from the node list.

15. A computer-readable storage medium having program instructions recorded thereon, which, when executed by a processor, perform the method according to any one of claims 8-14.

Images