System and method for protecting computer networks from man-in-the-middle attacks
By using distributed ledger technology to share key export parameters in computer networks and using trust voting to detect attacks, the problem of vulnerability to target key attacks in the prior art is solved, and the security of the network is improved.
Patent Information
- Application Number
- CN201980083274.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2018-12-18
- Filing Date
- 2019-12-08
- Publication Date
- 2025-02-28
- Estimated Expiration
- 2039-12-08
AI Technical Summary
The prior art is vulnerable to target key attacks when protecting computer networks from man-in-the-middle attacks, especially when relying on centralized or predictable key-derived parameter distribution schemes.
By using distributed ledger technology, key export parameters are securely shared among nodes, initializing network nodes with the master key, and detecting and defending attacks through trust votes.
It realizes the secure generation and sharing of key export parameters between computer network nodes, prevents man-in-the-middle attacks and target key attacks, and improves the security of the network.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
Field of the Invention
[0001] The present invention relates generally to computer networks. More particularly, the present invention relates to protecting computer networks from attacks such as man-in-the-middle attacks. Background of the Invention
[0003] Secure data exchange over potentially compromised communications networks may require the ability to exchange encryption keys or to independently generate encryption keys at either end of the communications channel. This is particularly important in the world of connected devices (e.g., devices that can exchange data, such as computers, household appliances, transportation equipment, etc.), where the number of entities requiring protected communications is growing rapidly.
[0004] Methods for generating one-time keys as known in the art generally assume that one or more computing devices in a network are initialized in a secure manner and derive a one-time secure key for a specific data transaction according to a predefined algorithm.
[0005] For example, a point of sale (POS) terminal associated in a computer network of a commercial organization (e.g., a shopping mall) may be preloaded with a master key. A first terminal may derive a one-time security key from its master key according to predefined parameters, referred to as key derivation parameters (KDP). The process is independently repeated by a device counterpart (e.g., by a second terminal, by a terminal management system, etc.), and the independently derived key is used to decrypt secure communications from the first terminal.
[0006] The KDP based on which the first terminal may derive the one-time key from the master key may be, for example, a sequential parameter such as a sequence number associated with a message on a message counter, a sequence number of a financial transaction, or the like.
[0007] As is known in the art, a man-in-the-middle (MITM) attack is an attack in which a perpetrator secretly relays and potentially alters communications between two parties who believe they are communicating directly with each other. In the above example, the perpetrator may have compromised the communication channel between one or more computing devices of the network (e.g., POS terminals, terminal management systems, etc.) and the bank's servers, and may be relaying messages between these parties.
[0008] Since the relayed message may still be encrypted by a one-time security key, the perpetrator may still be unable to decrypt its content. Therefore, the perpetrator may try to inject key derivation parameters to determine the value of at least one one-time key so that the relayed message can be decrypted. This type of attack is known in the art as a targeted-key attack or a selected-key attack.
[0009] Commercially available solutions for distributing key derivation parameters (KDP) rely on centralized schemes (e.g., through a central server) or fully predictable schemes, such as sequential notation, for distributing key derivation parameters. Such configurations are particularly vulnerable to targeted key attacks, as a perpetrator may only need to illegally hack into or attack a single node of a computer network, or act as a man-in-the-middle to successfully inject key derivation parameters into communications between nodes and access encrypted data traffic on the network in an undetectable manner.
[0010] Therefore, a need exists for a system and method for securely sharing key derivation parameters. SUMMARY OF THE INVENTION
[0012] Embodiments of the present invention include a system and method for generating and sharing peer-to-peer security keys between nodes of a computer network. Embodiments may use a master key value to initialize network nodes, generate a KDP for deriving a one-time security key, and securely share the KDP by two or more nodes of a computer network by utilizing distributed ledger technology, as described herein. Thus, embodiments may allow random generation and secure distribution of key derivation parameters in a manner that is protected from MITM KDP and / or security key injection attacks.
[0013] Embodiments of the present invention may include a system and method for detecting an attack on a computer network including a plurality of nodes. The method may include:
[0014] Associating multiple nodes with each other in a distributed ledger configuration;
[0015] generating, by a requesting node among the plurality of nodes, a request for setting a value of at least one key derivation parameter;
[0016] performing a confidence vote on the validity of the request among a subset of the plurality of nodes; and
[0017] An attack on at least one of the plurality of nodes is detected based on the confidence vote.
[0018] Embodiments of the present invention may be implemented to detect and / or protect against attacks against a computer network, where the attack may be one of a man-in-the-middle (MITM) attack, a selected key attack, and a targeted key attack.
[0019] Various embodiments may include loading a proprietary dedicated node key into each of the plurality of nodes. The first node may be configured to generate a request for setting a value of at least one key derivation parameter by:
[0020] selecting a value for at least one key derivation parameter;
[0021] sending a request message to a plurality of nodes other than the first node; and
[0022] The request message is signed using a proprietary, private node key.
[0023] The at least one second node may be configured to:
[0024] Verify the requesting node's signature on the request; and
[0025] Based on the verification, the key derivation parameter value is stored in an entry of the distributed ledger stored in a local copy at the second node.
[0026] According to some embodiments, a master key may be loaded into each of the plurality of nodes. At least one first node may:
[0027] deriving a security key based on the master key and based on key derivation parameters stored on a local copy of the distributed ledger at the first node;
[0028] encrypting the message according to the derived key; and
[0029] The encrypted message is sent along with an identification of the distributed ledger entry to at least one second node in the computer network.
[0030] According to some embodiments, at least one second node may request a confidence vote to be performed among a subset of nodes regarding the validity of the key derivation parameter value in the identified distributed ledger entry. If the confidence vote passes, the second node may derive a security key based on the key derivation parameter value and decrypt the encrypted message. If the confidence vote fails, the second node may identify the key derivation parameter value as being associated with a suspected attack on the computer network and perform at least one preventive measure therefor.
[0031] The countermeasure may be selected from a list including, for example, generating a notification about a suspected attack, blocking at least one message originating from the first node, isolating at least one message originating from the first node, and generating, by a node other than the first node, a request to change the value of at least one key derivation parameter.
[0032] The computer network may include multiple separate entities of homogeneous network topology. Each entity may include one or more nodes, and the nodes of all entities are associated in a distributed ledger configuration.
[0033] At least one first node of the first homogeneous network entity may be communicatively connected to at least one second node of the separate second homogeneous network entity via a secure connection. For example, the secure network connection between the homogeneous network entities may include any known physical or logical network security modules (e.g., firewalls, demilitarized zone networks (DMZs), etc.) known in the art to facilitate secure transactions of messages associated with trust voting for the distributed ledger configuration 30.
[0034] According to some embodiments, the at least one first node and the at least one second node may be implemented as nodes in a virtual private network (VPN).The secure network connection may be performed over a computer network.
[0035] Additionally or alternatively, the at least one first node and the at least one second node may be communicatively connected via a secure network connection separate from the computer network.
[0036] The computer network may include at least one processing center separate from the plurality of entities of the homogeneous network topology.In some embodiments, generating the request to set the value of at least one key derivation parameter may be performed by the processing center.
[0037] Embodiments of the present invention may include a system for detecting and / or deflecting an attack on a computer network, which may include a plurality of nodes. Each of the plurality of nodes may include:
[0038] a non-transitory memory device in which the instruction code module is stored, and
[0039] A processor is associated with the memory device and is configured to execute the instruction code module. When executing the instruction code module, the processor may be further configured to perform at least one method of detecting and / or diverting an attack on a computer network.
[0040] Embodiments of the present invention may include a method of detecting, by at least one processor, an attack on a computer network, the computer network may include a plurality of nodes. The method may include:
[0041] Create a distributed ledger that records transactions between multiple nodes;
[0042] creating, by at least one node, a request to set a value of at least one key derivation parameter;
[0043] voting among a subset of the plurality of nodes whether the request is valid; and
[0044] If the vote is that the request is invalid, an attack is detected. BRIEF DESCRIPTION OF THE DRAWINGS
[0046] The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. However, the invention as to its organization and method of operation, together with objects, features, and advantages thereof, may be best understood by reference to the following detailed description when read with the accompanying drawings, in which:
[0047] Figure 1 is a block diagram depicting a computing device that may be included in a system for protecting a computer network from attacks, such as man-in-the-middle attacks, according to some embodiments;
[0048] Figure 2 is a block diagram depicting a system for centralized distribution of key derivation parameters as known in the art;
[0049] Figure 3 is a block diagram depicting a system for protecting a computer network from attacks, such as man-in-the-middle attacks, according to some embodiments;
[0050] Figure 4 is a block diagram depicting data elements that may be included within one or more nodes of a computer network,
[0051] Figure 5 is a flow chart depicting a method for protecting a computer network from man-in-the-middle attacks according to some embodiments.
[0052] It should be understood that for simplicity and clarity of illustration, the elements shown in the drawings are not necessarily drawn to scale. For example, for clarity, the size of some elements may be exaggerated relative to other elements. In addition, where deemed appropriate, reference numerals may be repeated between the drawings to indicate corresponding or similar elements.
[0053] Detailed description of the invention
[0054] In the following detailed description, many specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be appreciated by those skilled in the art that the present invention may be implemented without these specific details. In other cases, well-known methods, processes and components are not described in detail to avoid obscuring the present invention. Some features or elements described about one embodiment may be combined with features or elements described about other embodiments. For clarity, the discussion of the same or similar features or elements may not be repeated.
[0055] Although embodiments of the present invention are not limited in this regard, terms such as, for example, "processing," "computing," "calculating," "determining," "establishing," "analyzing," "checking," and the like may refer to operations and / or processes of a computer, computing platform, computing system, or other electronic computing device that manipulates data represented as physical (e.g., electronic) quantities within a computer's registers and / or memory and / or converts it into other data similarly represented as physical quantities within a computer's registers and / or memory or other information of a non-transitory storage medium that may store instructions to perform operations and / or processes. Although embodiments of the present invention are not limited in this regard, the terms "plurality" and "a plurality" as used herein may include, for example, "multiple" or "two or more." The terms "plurality" or "a plurality" may be used throughout the specification to describe two or more components, devices, elements, units, parameters, and the like. When used herein, the term "set" may include one or more items. Unless explicitly stated, the method embodiments described herein are not constrained by a particular order or sequence. Additionally, some of the described method embodiments or elements thereof may occur or be performed simultaneously at the same point in time.
[0056] Embodiments of the present invention disclose a method and system for generating and sharing peer-to-peer security keys between nodes of a computer network to protect the network from MITM attacks, particularly from attacks commonly referred to in the art as selected key attacks. The term "node" is used herein to refer to a computing device (e.g., as described herein with respect to a Figure 1 ), which may be included in a computer communication network and may be interconnected with other such nodes in the network. For example, a node may be a POS terminal, a household appliance (e.g., a thermostat, a refrigerator), a component in a car, the vehicle itself, etc. Nodes may communicate with each other for a variety of reasons (e.g., cars exchanging location fixes, household appliances sending status information, etc.).
[0057] Reference now Figure 1 , Figure 1 is a block diagram depicting a computing device, according to some embodiments, that may be included in an embodiment of a system for protecting a computer network from man-in-the-middle attacks.
[0058] The computing device 1 may include a controller 2 (which may be, for example, a central processing unit (CPU) processor, a chip, or any suitable computing or computational device), an operating system 3, a memory 4, an executable code 5, a storage system 6, an input device 7, and an output device 8. The controller 2 (or one or more controllers or processors that may span multiple units or devices) may be configured to perform all or part of the methods described herein, and / or to perform or act as various modules, units, etc. More than one computing device 1 may be included, and one or more computing devices 1 may act as a component of a system according to an embodiment of the present invention.
[0059] The operating system 3 may be or may include any code segment (e.g., a code segment similar to the executable code 5 described herein) designed and / or configured to perform tasks related to coordinating, scheduling, arbitrating, supervising, controlling, or otherwise managing the operation of the computing device 1, such as scheduling the execution of software programs or tasks or enabling software programs or other modules or units to communicate. The operating system 3 may be a commercial operating system. It will be noted that the operating system 3 may be an optional component, for example, in some embodiments, the system may include a computing device that does not require or include an operating system 3.
[0060] The memory 4 may be or may include, for example, a random access memory (RAM), a read-only memory (ROM), a dynamic RAM (DRAM), a synchronous DRAM (SDRAM), a double data rate (DDR) memory chip, a flash memory, a volatile memory, a non-volatile memory, a buffer memory, a buffer, a short-term memory unit, a long-term memory unit, or other suitable memory unit or storage unit. The memory 4 may be or may include a plurality of possibly different memory units. The memory 4 may be a computer or processor non-transitory readable medium, or a computer non-transitory storage medium, such as a RAM.
[0061] Executable code 5 may be any executable code, such as an application, program, process, task, or script. Executable code 5 may be executed by controller 2, possibly under the control of operating system 3. For example, according to some embodiments as further described herein, executable code 5 may be an application that may protect a computer network from a man-in-the-middle attack. Although for clarity, in Figure 1 A single executable code 5 is shown in FIG. 1 , but a system according to some embodiments of the present invention may include multiple executable code segments similar to the executable code 5 , which may be loaded into the memory 4 and cause the controller 2 to execute the method described herein.
[0062] The storage system 6 may be or may include, for example, a flash memory known in the art, a memory inside or embedded in a microcontroller or chip known in the art, a hard disk drive, a CD-Recordable (CD-R) drive, a Blu-ray Disc (BD), a Universal Serial Bus (USB) device, or other suitable removable and / or fixed storage unit. Content may be stored in the storage system 6 or loaded from the storage system 6 into the memory 4, and then processed by the controller 2 in the memory 4. In some embodiments, the storage system 6 may be omitted. Figure 1 For example, memory 4 may be a non-volatile memory having the storage capacity of storage system 6. Thus, storage system 6 may be embedded or included in memory 4, although shown as a separate component.
[0063] The input device 7 may be or may include any suitable input device, component or system, such as a detachable keyboard or keypad, a mouse, etc. The output device 8 may include one or more (possibly detachable) displays or monitors, speakers, and / or any other suitable output device. As shown in boxes 7 and 8, any applicable input / output (I / O) device may be connected to the computing device 1. For example, a wired or wireless network interface card (NIC), a universal serial bus (USB) device, or an external hard drive may be included in the input device 7 and / or the output device 8. It will be appreciated that, as shown in boxes 7 and 8, any suitable number of input devices 7 and output devices 8 may be operably connected to the computing device 1.
[0064] Systems according to some embodiments of the present invention may include components such as, but not limited to, multiple central processing units (CPUs) or any other suitable general-purpose or specific processor or controller (e.g., a controller similar to controller 2), multiple input units, multiple output units, multiple memory units, and multiple storage units.
[0065] Reference now Figure 2 , Figure 2 A system for centralized distribution of key derivation parameters known in the art is described. Figure 2 As shown, the computer network 20 may include one or more computing devices that may be communicatively interconnected via wired and / or wireless network components including, for example, network hubs, switches, routers, and gateways in a computer network, as is known in the art.
[0066] For example, the elements T (eg, T1-A to T3-C) may be terminal computers, and each may be or may include at least one computing device (eg, Figure 1The terminals T1-A to T3-C may be interconnected, for example, via a local area network (LAN), a wide area network (WAN) such as the Internet, a cellular network, etc.
[0067] In another example, T1-A to T3-C may be divided into smaller homogeneous local networks. For example: T1-A, T1-B, and T1-C may be terminals associated with a first organizational computer network (e.g., of merchant M1), T2-A, T2-B, and T2-C may be terminals associated with a second organizational computer network (e.g., of merchant M2), and T3-A, T3-B, and T3-C may be terminals associated with a third organizational computer network (e.g., of merchant M3).
[0068] The term "homogenous" is used herein with respect to a local network (e.g., M1) to refer to at least one parameter that may be common to all computing devices included in the local network. For example, the local network M1 may be homogeneous in the following sense: it may include a single network segment having a direct connection to at most one network switching and / or routing element; and it may be included in a single address space, such as a subnet of an Internet Protocol (IP) network as known in the art.
[0069] In another example, at least one computing device T (e.g., T1-A to T3-C) may be connected to the processing center 10. With respect to the example of computing devices, namely T1-A to T3-C being POS terminals installed on a computer network of one or more merchants, the processing center 10 may be a bank server configured to receive at least one parameter of a commercial transaction (e.g., a personal identification number (PIN) of a credit card). In a typical embodiment, the processing center 10 may be a well-secured computing system that may be difficult to penetrate or hack into (e.g., by physically accessing a communication line or channel therein) and may be used to distribute security keys and / or KDPs.
[0070] like Figure 2 As shown, at least one computing system (e.g., T1-A to T3-C, processing center 10) can distribute security keys and / or KDP R1 to one or more computing devices in network 20. Criminal P1 (represented here by computing device P1; criminal P1 is typically a person such as Figure 1A computing device (a computing device that may be remotely operated by a person) may hack into or attack the communication channel between the first computing device that distributes the security keys and / or KDP and the second target computing device to establish a man-in-the-middle (MITM) configuration, as indicated by the "X" symbol. In this configuration, perpetrator P1 can alter the communication between the first computing device and the second computing device. Specifically, perpetrator P1 can change or inject a key derivation parameter (KDP) R1' that may be different from R1 to set the value of at least one derived security key and thereby be able to decrypt data that may be passed between the first computing device and the second computing device.
[0071] Reference now Figure 3 , Figure 3 is a block diagram depicting a system 100 for protecting a computer network (eg, computer network 20) from attacks (such as MITM attacks) according to some embodiments. Figure 4 ,Should Figure 4 is a block diagram depicting data elements that may be included within one or more nodes T of computer network 20. Figure 3 As shown, the structure of the computer network 20 included in the system 100 can be the same as that described in this article. Figure 2 The structures described are basically the same.
[0072] According to some embodiments, each node T (eg, T1-A to T3-C) may be initialized or loaded with a secret master key (eg, Figure 4 , which can be used to derive a one-time security key (e.g., Figure 4 of element 50C), as known in the art.
[0073] Additionally or alternatively, each node T may also (e.g., Figure 1 A separate, proprietary, dedicated node key (e.g., Figure 4 Element 40B of ) and a trusted public root certificate (e.g. Figure 4 Elements 40A) that can be used to send signed messages between nodes T, as is known in the art and as described herein.
[0074] Protecting the computer network 20 from attacks such as MITM attacks may be based on sharing information between two or more computing devices T (eg, T1 -A through T3 -C) via a distributed ledger 30 configuration.
[0075] As known in the art, the distributed ledger 30 may be a distributed database shared, replicated, and synchronized between nodes T of a decentralized network (e.g., network 20) without the use of a central authority or third-party intermediary. As known to those skilled in the art of blockchain and / or distributed ledger databases, the term "distributed" is used herein to indicate that the database is not maintained or stored by a single computing device or entity, but is cumulatively saved by two or more nodes T (e.g., on multiple copies).
[0076] The distributed ledger 30 may record transactions (e.g., data exchanges between nodes T in the network 20), and may store the recorded data in a local copy of the distributed database. The term "local" is used herein to imply that the recorded data is stored in a storage device (e.g., a storage device) that may be included in or associated with a particular computing device (e.g., a particular node T participating in the distributed ledger 30). Figure 1 6) or a memory device (e.g., Figure 1 On the element 4).
[0077] Each record in a distributed ledger can have a timestamp and / or a unique cryptographic signature, making the ledger an auditable history of transactions in the network.
[0078] As is known in the art, nodes T participating in the ledger 30 may govern updates to records in the ledger 30 and reach consensus on the updates. For example, a first node T may initiate a vote and communicate a voting request to at least a subset of the other participating nodes T. Each node in the subset of nodes T may receive the request and vote by responding to the requested vote (e.g., with a binary true / false answer). Each node in the subset of nodes T may receive their respective responses (e.g., from all other voting nodes T) (e.g., Figure 4 60A), and can be counted in the overall vote count (e.g., Figure 4 The voting responses are accumulated in element 60B of Node T. Thus, each node in the subset of nodes T can determine (e.g., in a separate, distributed manner) whether the vote has passed or failed based on the majority vote in vote count 60B. Each node in the subset of nodes T can then update their local copy of the distributed database based on the result of the vote (e.g., passed or failed).
[0079] An administrative user may create a distributed ledger configuration 30 and (e.g., via Figure 1 The input device 7) configures one or more nodes T (e.g., T1-A, T1-B, etc.) of the network 20 to be included in the distributed ledger configuration 30.
[0080] One or more nodes T (e.g., T1-A to T3-C) may be configured (e.g., by an administrator) to participate in or be included in a distributed ledger 30 configuration. As is known in the art, each participating node may be associated with each other participating node in the distributed ledger 30 in the sense that each node may be configured (e.g., by an administrator) to recognize data transmissions that may originate from all other associated nodes T participating in the ledger 30.
[0081] Each node T participating in the distributed ledger 30 may maintain distributed information about the KDP and / or security keys of the network 20. The nodes T may be interconnected (e.g., via the network 20) and may communicate therebetween to synchronize information associated with the distributed KDP 50B and / or security keys of the network 20 as is known in the art of distributed ledgers.
[0082] At least one node T may include a storage device (e.g., Figure 1 6) or may be associated with a storage device on which node T may maintain a database. The database may include at least one entry including a distributed KDP (e.g., Figure 4 In some embodiments, the distributed KDP information 50B may include the value of at least one specific KDP and a corresponding timestamp corresponding to the time when the node T may have received the specific KDP.
[0083] like Figure 3 As shown, a computing device of the computer network 20 (eg, node T, processing center 10, etc.) may select at least one key derivation parameter (KDP) value and generate a request R2 to set the KDP value, thereby generating a one-time derived security key value.
[0084] The requesting computing device (e.g., node T) may send a request message R2 including the requested value to other nodes T in the distributed ledger 30 (e.g., other than the requesting node T), and may sign the request message with its proprietary dedicated node key 40B and trusted root certificate 40A as known in the art.
[0085] For example, the requesting node (e.g., T1-A) may sign the request message R2 using a dedicated dedicated node key 40B that is dedicated to signing outgoing messages. As is known in the art, the dedicated dedicated node key 40B itself may be signed by a certificate 40A of a trusted root entity such as a certificate authority (CA). A receiving entity (e.g., a node T1-B other than the requesting node T1-A) may receive the request message R2 and may verify the signature of the requesting node T1-A in at least one of the following ways:
[0086] If the receiving entity T1 -B knows and trusts the private dedicated node key 40B of the requesting node T1 -A, T1 -B can verify the authenticity of the request message R2 based on the value of the private dedicated node key 40B of the requesting node T1 -A.
[0087] If the receiving entity T1-B does not know and / or trust the proprietary dedicated node key 40B of the requesting node T1-A, T1-B may verify the authenticity of the request message R2 based on a certificate 40A of a trusted root entity (eg, a certificate authority).
[0088] A subset of nodes T participating in the distributed ledger 30 (e.g., two or more nodes) may perform or participate in a confidence vote (also known in the art as a consensus vote) regarding the validity of the request.
[0089] For example, if the request R2 is signed using a trusted root certificate 40A and / or a valid private key 40B signed by the first requesting node T (e.g., T1-A), the second node T (e.g., T2-B) participating in the consensus vote may vote to approve the changed KDP (e.g., vote: "true"). In a complementary manner, if the request is not correctly signed as described, the second node T (e.g., T2-B) may vote against the change (e.g., vote: "false").
[0090] As described in detail herein, each node T participating in the vote may individually and in a distributed manner count the voting responses 60A and determine (e.g., based on a majority of votes in the voting count 60B) whether the vote has passed or failed.
[0091] Thus, the system 100 can generally determine whether a request to set a KDP value originates from a legitimate request (e.g., a request by a node T of the computer network 20, such as nodes T1-A to T3-C or the processing center 10) or whether it originates from an attack such as a MITM attack initiated by a criminal P1, the determination being based on the results of the following confidence vote or consensus vote:
[0092] If the vote fails (e.g., a majority of nodes vote against the change), the member nodes T of the distributed ledger 30 may determine that the request is invalid and that an attack (e.g., a MITM attack) on at least one node T has occurred.
[0093] If the consensus vote passes or succeeds (e.g., the votes indicating legitimacy are greater than the votes indicating an attack), the member node T of the distributed ledger 30 can determine that the request to set the KDP is legitimate.
[0094] At least one second node T among the nodes participating in the vote may verify the signature of the requesting node on the request R2. For example, the second node T may verify that the key used to sign the request R2 is signed by a root certificate authority (CA). The at least one second node T may then store the KDP value included in the request R2 in an entry 50B of a local copy of the distributed ledger (e.g., in Figure 1 Element 6).
[0095] By comparison Figure 2 and Figure 3 Compared with the prior art (such as Figure 2 Improvements (such as those described in Figure 3 ) are apparent as described in detail herein.
[0096] like Figure 2 and Figure 3 As shown, the computer network 20 may include two or more separate entities (e.g., M1, M2, M3) of a homogeneous network topology, each entity including one or more nodes (e.g., T1-A, T1-B, and T1-C for M1, etc.). For example, M1 may be a LAN associated with a particular merchant or store, and T1-A, T1-B, and T1-C may be POS terminals included in the LAN of M1.
[0097] In some embodiments, the computer network 20 may include at least one processing center 10 (e.g., a bank server) that is separate from two or more entities (e.g., merchant networks M1, M2, M3) of a homogeneous network topology. Figure 2 and Figure 3 As depicted in the example of , in some centralized constellations of network 20 , processing center 10 may generate a request ( R1 , R2 ) to set a value of at least one key derivation parameter.
[0098] exist Figure 3 In the distributed ledger configuration 30, different nodes T of all entities can be configured to participate in the distributed ledger configuration 30, or be associated with or linked in the distributed ledger configuration 30, as described herein. For example, at least one computing system or node T (e.g., T1-A) of a first homogeneous network entity (e.g., M1) can be securely connected (e.g., C1) to at least one computing system or node T (e.g., T2-A) of a second homogeneous network entity (e.g., M2).
[0099] As is known in the art, the secure network connection (e.g., C1, C2) between homogeneous network entities (e.g., M1, M2, M3) may include any known physical or logical network security module (e.g., firewall, demilitarized zone network (DMZ), etc.) to facilitate secure traffic of messages associated with trust voting for the distributed ledger configuration 30. In some embodiments, the secure network connection (e.g., C1, C2) may only facilitate traffic of messages related to trust voting for the distributed ledger configuration 30, and may not transmit messages related to other communications over the computer network 20.
[0100] For example, at least two nodes (e.g., T1-A and T2-A) of separate homogeneous network entities (e.g., M1 and M2, respectively) can be implemented as nodes in a virtual private network (VPN), and the secure network connection C (e.g., C1, C2) can communicate over an existing public Internet connection. In another example, T1-A and T2-A can be implemented as nodes in a license-free sub-GHz wireless wide area network (WAN). In yet another example, T1-A and T2-A can be implemented as nodes in a VPN network, and the secure network connection C can communicate using a wireless modem to utilize an Internet connection separate from the Internet connection of the processing center 10.
[0101] Additionally or alternatively, at least two devices (eg, devices belonging to different homogeneous network topology entities M) may communicate directly with each other instead of communicating through the network 20 .
[0102] like Figure 2 and Figure 3 As shown, perpetrator P1 may hijack or infiltrate (e.g., participate without permission or by impersonation) a communication connection link or line between two entities of computer network 20 (e.g., a physical cable line connecting between computer network entities such as routers, switches, hubs, etc.) to inject KDP according to their preferences. For example, as depicted in both figures, perpetrator P1 may hijack the communication between processing center 10 and at least one node T of homogeneous network entity M1. Perpetrator P1 may therefore generate malicious requests (e.g., R1', R2') for setting KDP on homogeneous network entity M1.
[0103] exist Figure 2 , representing an example of the prior art, perpetrator P1 may have successfully injected R1' and thus become able to decrypt messages transmitted within homogeneous network entity M1 and between M1 and processing center 10. In this case, implementing additional distributed security measures (such as a blockchain or distributed ledger) between the nodes of M1 will not solve this problem.
[0104] On the contrary, as described in the example of the embodiment of the present invention Figure 3 As shown, perpetrator P1 may initially seek to "trick" at least one terminal (e.g., T1-A) of M1 into believing that request R2' is legitimate, but subsequent trust voting between computing devices participating in the distributed ledger 30 (e.g., terminal nodes, including nodes from outside M1 (e.g., nodes T of entities M2 and M3)) over secure communication channels (e.g., C1, C2) may detect and prevent the attack. For example, nodes T of M2 and M3 may vote against the malicious KDP contained in R2' because they have not yet received message R2' from perpetrator P1, resulting in an overall vote against the KDP of R2'. Each node T participating in the vote can independently count the voting responses 60A of all other participating nodes T, and can therefore individually determine that an attack has been attempted.
[0105] In order to "spoof" (e.g., inject a selected KDP) a terminal (e.g., T1-A) of a homogeneous network entity (e.g., M1), perpetrator P1 may need to hijack or infiltrate multiple communication connections concurrently in order to bypass the defenses provided by the distributed ledger 20. In this context, the term "concurrently" is used to indicate a sufficiently close time frame to prevent the system 100 from identifying an attack via a first communication connection and taking preemptive measures before launching an attack via a second communication connection.
[0106] For example, offender P1 may need to:
[0107] Concurrently hijack the communication between processing center 10 and M1 (as shown) and the communication between processing center 10 and M2; or
[0108] The concurrent hijacking process handles communications between the center 10 and M1 (as shown) and C1 (between M1 and M2), and so on.
[0109] This requirement greatly reduces the likelihood of a successful attack and provides superior security over existing techniques.
[0110] As described herein, a node T of a distributed ledger 30 may include in a request (e.g., Figure 3 The KDP value 50B in R2) is stored in an associated storage device (e.g., Figure 1 In some embodiments, during or after at least one data transaction on network 20, node T of distributed ledger 30 may perform a confidence vote or a consensus vote on the validity of at least one locally stored KDP value 50B.
[0111] For example, the first node T may receive a request (e.g., R2, R2') to set a KDP value (e.g., from a requesting node T, from a processing center 10, from a criminal P1, etc.) and may store the value 50B in an entry in a local copy of the distributed ledger 30.
[0112] It may be desirable for the first node T to send an encrypted message to a second node T in the network 20. Therefore, the first node T may derive a security key 50C from its master key 50A and from a locally stored KDP 50B to produce a derived security key, as is known in the art. The first node T may then encrypt the message based on the derived security key 50C, as is known in the art.
[0113] According to some embodiments, the first node T may then send the encrypted message to the second node T (along with, in conjunction with, or in the same communication as an identification of the distributed ledger entry (e.g., a timestamp of when the corresponding request R2 was received)).
[0114] The second node T may send a request message to at least a subset of the nodes of the distributed ledger 30, including a request to perform a trust vote or a consensus vote from the subset of nodes T to confirm the validity of a key derivation parameter (KDP) value in the identified distributed ledger entry.
[0115] As described herein, if the second node T determines that the trust vote has passed or succeeded (for example, more than 50% of the nodes T in the node subset agree with the value of the KDP, or vote that the KDP is legitimate), the second node T can derive a security key 50C based on the KDP value 50B and based on its own master key 50A to decrypt the encrypted message.
[0116] On the other hand, as described herein, if the second node T determines that the trust vote has failed, or determines that the KDP is not legitimate (e.g., 50% or less of the node subset T agree with the KDP value or vote that the KDP is legitimate), the second node T may identify the KDP value as being associated with a suspected attack on the computer network 20 (e.g., a MITM attack).
[0117] In some embodiments, having identified the KDP as originating from a suspected attack such as a MITM attack, the second node T may take at least one preventive measure to repel or defend against the suspected attack.
[0118] For example, the second node T may generate a warning notification regarding a suspected MITM attack (eg, via Figure 1The message may include, for example, at least one parameter associated with the origin of the attack (e.g., an identification of the requesting node, an identification of the first node, etc.), the time of the attack (e.g., a timestamp contained in an entry in the local copy of the distributed ledger), etc.
[0119] In some embodiments, the second node T may display the content of the warning notification to the management user (for example, in Figure 1 The management user can take the desired actions according to their considerations (displayed on the user interface included in the output device 8).
[0120] Alternatively or additionally, at least one computing device in the computer network 20 (e.g., a third node T other than the second node T) may receive the warning notification and may store the warning notification in a storage device (e.g., Figure 1 The storage device 6) stores the content of the warning notification, such as the timing of the suspected attack and the attributes of the nodes involved.
[0121] The third node T may be configured to subsequently apply safety measures according to the stored warning notification. For example, the third node T may perform at least one of the following:
[0122] blocking at least one message that may have originated from the first node;
[0123] isolating at least one message originating from the first node;
[0124] generating a request (e.g., R2) to change the value of at least one uncorrupted KDP;
[0125] A second alert notification is generated to one or more other nodes T regarding the message received from the first node T, and so on.
[0126] Reference now Figure 5 , Figure 5 is a diagram illustrating a method for detecting and / or protecting a computer network including a plurality of nodes T (eg, Figure 3 Element 20) is a flowchart of a method for protecting against attacks (e.g., MITM attacks).
[0127] As shown in step S1005 , a plurality of nodes may be associated with each other (eg, by an administrator) in a distributed ledger configuration.
[0128] As shown in step S1010, at least one processor (eg, Figure 1 Element 2) may generate a request for setting a value of at least one key derivation parameter (KDP).
[0129] As shown in step S1015 , as known to those skilled in the art, at least one processor 2 of node T may perform a confidence vote or a consensus vote on the validity of the request among a subset of the plurality of nodes.
[0130] As shown in step S1020 , at least one processor 2 of the node T may detect an attack on at least one node T among the plurality of nodes of the computer network 20 based on the trust vote.
[0131] Embodiments of the present invention provide methods for improving the security of a computer communication network (e.g., against MITM attacks) by forcing a criminal to concurrently hijack or infiltrate (e.g., participate without permission or through impersonation) multiple communication connection links or lines of a computer network 20 (e.g., physical cable lines connecting between computer network entities such as routers, switches, hubs, etc.).
[0132] According to embodiments of the present invention, attacks, security breaches or penetrations other than MITM attacks may be detected and action may be taken thereon.
[0133] While certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents will now occur to those skilled in the art. It is therefore to be understood that the appended claims are intended to cover all such modifications and changes that fall within the true spirit of the invention.
[0134] Aspects of the present disclosure may be implemented in one or more of the following embodiments.
[0135] 1) A method for detecting, by at least one processor, an attack on a computer network comprising a plurality of nodes, the method comprising:
[0136] Associating the plurality of nodes with each other in a distributed ledger configuration;
[0137] generating, by a requesting node among the plurality of nodes, a request for setting a value of at least one key derivation parameter;
[0138] performing a confidence vote among a subset of the plurality of nodes regarding the validity of the request; and
[0139] An attack on at least one of the plurality of nodes is detected based on the trust vote.
[0140] 2) The method according to 1), wherein the attack is one of a man-in-the-middle (MITM) attack, a selected key attack, and a target key attack.
[0141] 3) The method according to any one of 1) to 2), comprising: loading a dedicated dedicated node key to each of the plurality of nodes, and wherein the request for setting the value of at least one key derivation parameter generated by the requesting node comprises:
[0142] selecting a value for at least one key derivation parameter;
[0143] sending a request message to the plurality of nodes except the requesting node; and
[0144] The request message is signed using the proprietary dedicated node key.
[0145] 4) The method according to any one of 1) to 3), wherein at least one other node is configured to:
[0146] verifying the requesting node's signature on the request; and
[0147] Based on the verification, storing the value of the at least one key derivation parameter in an entry of the distributed ledger stored in a local copy at the at least one other node.
[0148] 5) The method according to any one of 1) to 4), comprising:
[0149] loading a master key into each of the plurality of nodes;
[0150] deriving, by the requesting node, a security key based on the master key and based on key derivation parameters stored on a local copy at the requesting node;
[0151] The requesting node encrypts the message according to the derived key;
[0152] The encrypted message is sent along with the identification of the distributed ledger entry to the at least one other node in the computer network.
[0153] 6) The method according to any one of 1) to 5), comprising:
[0154] requesting, by the at least one other node, a confidence vote from the subset of nodes regarding the validity of the value of the at least one key derivation parameter in the identified distributed ledger entry;
[0155] If the trust vote passes, the at least one other node derives a security key according to the value of the at least one key derivation parameter and decrypts the encrypted message;
[0156] If the confidence vote fails, the value of the at least one key derivation parameter is identified as being associated with a suspected attack on the computer network and at least one preventive measure is performed thereon.
[0157] 7) The method according to 6), wherein the preventive measure is selected from a list comprising: generating a notification about the suspected attack, blocking at least one message originating from the requesting node, isolating at least one message originating from the requesting node, and generating a request for changing the value of at least one key derivation parameter by a node other than the requesting node.
[0158] 8) A method according to any one of 1) to 7), wherein the computer network comprises a plurality of separate entities of a homogeneous network topology, each entity comprising one or more nodes, and wherein the nodes of all entities are associated in a distributed ledger configuration.
[0159] 9) The method according to any one of 1) to 8), wherein at least one first node of a first homogeneous network entity is communicatively connected to at least one second node of a separate second homogeneous network entity via a secure network connection.
[0160] 10) The method according to 9), wherein the at least one first node and the at least one second node are implemented as nodes in a virtual private network (VPN), and wherein the secure network connection is performed through the computer network.
[0161] 11) The method according to any one of 9) to 10), wherein the at least one first node and the at least one second node are communicatively connected via a secure network connection separate from the computer network.
[0162] 12) A method according to any one of 1) to 11), wherein the computer network includes at least one processing center separated from multiple entities of a homogeneous network topology, and wherein generating a request for setting the value of at least one key derivation parameter is executed by the processing center.
[0163] 13) A system for detecting an attack on a computer network comprising a plurality of nodes, wherein each node comprises:
[0164] a non-transitory memory device having a command code module stored therein, and
[0165] a processor associated with the memory device and configured to execute the instruction code module, wherein when executing the instruction code module, the processor is further configured to:
[0166] Associating the plurality of nodes with each other in a distributed ledger configuration;
[0167] generating, by a requesting node among the plurality of nodes, a request for setting a value of at least one key derivation parameter;
[0168] performing a confidence vote among a subset of the plurality of nodes regarding the validity of the request; and
[0169] An attack on at least one of the plurality of nodes is detected based on the confidence vote.
[0170] 14) The system according to 13), wherein the attack is one of a MITM attack, a selected key attack and a target key attack.
[0171] 15) A system according to any one of 13) to 14), wherein each of the plurality of nodes is loaded with a proprietary dedicated node key, and wherein at least one processor of the requesting node is configured to generate a request for setting a value of at least one key derivation parameter by:
[0172] selecting a value for at least one key derivation parameter;
[0173] sending a request message to the plurality of nodes except the requesting node; and
[0174] The request message is signed using the proprietary dedicated node key.
[0175] 16) The system according to any one of 13) to 15), wherein at least one processor of at least one node other than the requesting node is configured to:
[0176] verifying the requesting node's signature on the request; and
[0177] Based on the verification, the value of the at least one key derivation parameter is stored in an entry of the distributed ledger stored in a local copy at the other node.
[0178] 17) A system according to any one of 13) to 16), wherein each of the plurality of nodes is loaded with a master key, and wherein at least one processor of the requesting node is configured to:
[0179] deriving a security key based on the master key and based on key derivation parameters stored on a local copy at the requesting node;
[0180] encrypting the message according to the derived key; and
[0181] The encrypted message is sent along with the identification of the distributed ledger entry to at least one other node in the computer network.
[0182] 18) A system according to any one of 13) to 17), wherein at least one processor of the at least one other node is configured to:
[0183] requesting, from the subset of nodes, a confidence vote regarding the validity of the value of the at least one key derivation parameter in the identified distributed ledger entry;
[0184] If the confidence vote passes, deriving a security key based on the value of the at least one key derivation parameter and decrypting the encrypted message; and
[0185] If the confidence vote fails, the value of the at least one key derivation parameter is identified as being associated with a suspected attack on the computer network and at least one preventive measure is performed thereon.
[0186] 19) The system according to 18), wherein at least one processor is configured to perform at least one preventive measure selected from the list consisting of:
[0187] generating a notification regarding the suspected attack;
[0188] blocking at least one message originating from the first node;
[0189] isolating at least one message originating from the first node; and
[0190] A request to change the value of the at least one key derivation parameter is generated by a processor of a node other than the first node.
[0191] 20) A system according to any one of 13) to 19), wherein the computer network comprises multiple separate entities of a homogeneous network topology, each entity comprises one or more nodes, and wherein the nodes of all entities are associated in a distributed ledger configuration.
[0192] 21) The system according to any one of 13) to 20), wherein at least one first node of a first homogeneous network entity is communicatively connected to at least one second node of a separate second homogeneous network entity through a secure network connection.
[0193] 22) A system according to any one of 13) to 21), wherein the computer network includes at least one processing center separated from multiple entities of a homogeneous network topology, and wherein generating a request for setting the value of at least one key derivation parameter is executed by the processing center.
[0194] 23) A method of detecting, by at least one processor, an attack on a computer network comprising a plurality of nodes, the method comprising:
[0195] Creating a distributed ledger recording transactions between the plurality of nodes;
[0196] creating, by at least one node, a request to set a value of at least one key derivation parameter;
[0197] voting among a subset of the plurality of nodes whether the request is valid; and
[0198] If the result of the voting is that the request is invalid, an attack is detected, wherein the computer network includes multiple separate entities of a homogeneous network topology, each entity includes one or more nodes, and wherein at least one first node of a first homogeneous network topology entity is connected to at least one second node of a second homogeneous network topology entity via a secure network connection.
[0199] 24) The method according to 23), wherein the at least one first node and the at least one second node are implemented as nodes in a virtual private network (VPN), and wherein the secure network connection is performed through the computer network.
[0200] 25) The method according to 23), wherein the secure network connection is separate from the computer network.
Claims
1. A method of detecting, by at least one processor, an attack on a computer network comprising a plurality of nodes, the method comprising: Associating the plurality of nodes with each other in a distributed ledger configuration; loading a master key into each of the plurality of nodes; deriving, by at least one first node, a security key based on the master key and based on at least one key derivation parameter stored on a local copy of the distributed ledger at the at least one first node; encrypting, by the at least one first node, a message according to the derived key; sending the encrypted message together with an identification of the distributed ledger entry to at least one second node in the computer network; requesting, by the at least one second node, a confidence vote from a subset of nodes regarding the validity of the value of the at least one key derivation parameter in the identified distributed ledger entry; If the trust vote passes, the at least one second node derives a security key according to the value of the at least one key derivation parameter and decrypts the encrypted message; If the confidence vote fails, the value of the at least one key derivation parameter is identified as being associated with a suspected attack on the computer network and at least one preventive measure is performed thereon.
2. The method according to claim 1, wherein: The attack is one of a man-in-the-middle (MITM) attack, a chosen key attack, and a targeted key attack.
3. The method according to any one of claims 1 to 2, comprising: loading a proprietary dedicated node key to each of the plurality of nodes, and wherein generating, by the at least one first node, a request to set a value of at least one key derivation parameter comprises: selecting a value for at least one key derivation parameter; sending a request message to the plurality of nodes excluding the at least one first node; and The request message is signed using the proprietary dedicated node key.
4. The method according to any one of claims 1 to 3, wherein: The at least one second node is configured to: verifying a signature of the request by the at least one first node; as well as Based on the verification, storing the value of the at least one key derivation parameter in an entry of the distributed ledger stored in the local copy at the at least one second node.
5. The method according to claim 1, wherein: The countermeasure is selected from a list comprising: generating a notification about the suspected attack, blocking at least one message originating from the at least one first node, isolating at least one message originating from the at least one first node, and generating, by a node other than the at least one first node, a request to change the value of the at least one key derivation parameter.
6. The method according to any one of claims 1 to 5, wherein: The computer network includes a plurality of separate entities of a homogeneous network topology, each entity includes one or more nodes, and wherein the nodes of all entities are associated in a distributed ledger configuration.
7. The method according to claim 6, wherein: At least one first node of a first homogeneous network entity is communicatively connected to at least one second node of a separate second homogeneous network entity via a secure network connection.
8. The method according to claim 7, wherein: The at least one first node and the at least one second node are implemented as nodes in a virtual private network (VPN), and wherein the secure network connection is performed through the computer network.
9. The method according to any one of claims 7 to 8, wherein: The at least one first node and the at least one second node are communicatively coupled via a secure network connection separate from the computer network.
10. The method according to any one of claims 6 to 9, wherein: The computer network comprises at least one processing center separate from the plurality of entities of the homogeneous network topology, and wherein generating the request for setting the value of at least one key derivation parameter is performed by the processing center.
11. A system for detecting an attack on a computer network comprising a plurality of nodes, in, Each node consists of: a non-transitory memory device having an instruction code module stored therein, and a processor associated with the memory device and configured to execute the instruction code module, wherein when executing the instruction code module, the processor is configured to: Associating the plurality of nodes with each other in a distributed ledger configuration; loading a master key into each of the plurality of nodes; deriving, by at least one first node, a security key based on the master key and based on at least one key derivation parameter stored on a local copy of the distributed ledger at the at least one first node; encrypting, by the at least one first node, a message according to the derived key; sending the encrypted message together with an identification of the distributed ledger entry to at least one second node in the computer network; requesting, by the at least one second node, a confidence vote from a subset of nodes regarding the validity of the value of the at least one key derivation parameter in the identified distributed ledger entry; If the trust vote passes, the at least one second node derives a security key according to the value of the at least one key derivation parameter and decrypts the encrypted message; If the confidence vote fails, the value of the at least one key derivation parameter is identified as being associated with a suspected attack on the computer network and at least one preventive measure is performed thereon.
12. The system according to claim 11, wherein: The attack is one of a man-in-the-middle MITM attack, a selected key attack, and a targeted key attack.
13. The system according to any one of claims 11 to 12, wherein: Each of the plurality of nodes is loaded with a proprietary dedicated node key, and wherein at least one processor of the requesting node is configured to generate a request for setting a value of at least one key derivation parameter by: selecting a value for at least one key derivation parameter; sending a request message to the plurality of nodes except the requesting node; and The request message is signed using the proprietary dedicated node key.
14. A system according to any one of claims 11 to 13, wherein: At least one processor of at least one node other than the requesting node is configured to: Verifying the signature of the request by the requesting node; as well as Based on the verification, the value of the at least one key derivation parameter is stored in an entry of the distributed ledger stored in a local copy at the other node.
15. The system according to claim 11, wherein: The at least one processor is configured to perform at least one countermeasure selected from the list consisting of: generating a notification regarding the suspected attack; blocking at least one message originating from at least one first node; isolating at least one message originating from the at least one first node; as well as A request to change the value of the at least one key derivation parameter is generated by a processor of a node other than the at least one first node.
16. A system according to any one of claims 11 to 15, wherein: The computer network includes a plurality of separate entities of a homogeneous network topology, each entity includes one or more nodes, and wherein the nodes of all entities are associated in a distributed ledger configuration.
17. The system of claim 16, wherein: At least one first node of a first homogeneous network entity is communicatively connected to at least one second node of a separate second homogeneous network entity via a secure network connection.
18. A system according to any one of claims 16 to 17, wherein: The computer network comprises at least one processing center separate from the plurality of entities of the homogeneous network topology, and wherein generating the request for setting the value of at least one key derivation parameter is performed by the processing center.
19. A method of detecting, by at least one processor, an attack on a computer network comprising a plurality of nodes, the method comprising: Creating a distributed ledger recording transactions between the plurality of nodes; loading a master key into each of the plurality of nodes; deriving, by at least one first node, a security key based on the master key and based on at least one key derivation parameter stored on a local copy of the distributed ledger at the first node; encrypting, by the at least one first node, a message according to the derived key; sending the encrypted message together with an identification of the distributed ledger entry to at least one second node in the computer network; requesting, by the at least one second node, a confidence vote from a subset of nodes regarding the validity of the value of the at least one key derivation parameter in the identified distributed ledger entry; If the trust vote passes, the at least one second node derives a security key according to the value of the key derivation parameter and decrypts the encrypted message; If the confidence vote fails, the value of the at least one key derivation parameter is identified as being associated with a suspected attack on the computer network and at least one preventive measure is performed thereon.
20. The method according to claim 19, wherein: The at least one first node and the at least one second node are implemented as nodes in a virtual private network (VPN), and wherein the secure network connection is performed through the computer network.
21. The method according to claim 19, wherein: The secure network connection is separate from the computer network.
22. A non-transitory computer-readable storage medium storing instructions which, when executed by a processor, cause the processor to perform the method according to any one of claims 1-10.
Citation Information
Patent Citations
Distributed voting mechanism for attack detection
CN106416182A
Accession control for network nodes
WO2018073482A1