Wireless communication device, wireless communication management device, and wireless communication system

Abstract

To provide a wireless communication device, wireless communication management device, and wireless communication system capable of suppressing DoS attacks on a DTN and also capable of suppressing DDoS attacks on the DTN.SOLUTION: This wireless communication device is characterized by including: token receiving means for receiving a server-signed secure token indicating constraints for when a node is permitted to generate a message; message generating means for generating a secure message containing the secure token received by the token receiving means, generated data that have been generated, and a node signature for the secure token and the generated data; and wireless receiving means for receiving a secure message from another node, and if it is determined that the server signature of the secure token of the secure message and the node signature of the secure message are authentic and the secure message satisfies the constraints of the secure token, recording a reception history and receiving the secure message, or discarding the secure message if it is determined that the secure message is not authentic or is a duplicate.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a wireless communication device, a wireless communication management device, and a wireless communication system that perform data communication by a store-and-forward function using wireless communication that is intermittently available. [Background technology]

[0002] A Hybrid DTN has been proposed, which improves performance by adding a long-distance wireless delivery status notification function to a DTN (Delay and Disruption Tolerant Network). It is expected to provide relatively high-capacity communication services in areas where broadband public networks are underdeveloped.

[0003] Conventional Internet technology assumes that an end-to-end communication path between a source node and a destination node exists stably throughout the communication period. However, in interplanetary communication or ad hoc communication between mobile devices, the links in a communication path consisting of a chain of multiple links are only available intermittently, and it is necessary to assume that an end-to-end communication path does not exist between the source node and the destination node at any given time. To enable data communication even in such situations, research and development is being conducted on DTN (Delay and Disruption Tolerant Network) technology. For communication between mobile devices such as automobiles, a method has been proposed in which a store-and-forward DTN is used for short-range vehicle-to-vehicle communication.

[0004] In such DTN systems, there is a trade-off between the data delivery rate to the destination and the amount of redundant traffic. However, a hybrid DTN has been proposed that solves this trade-off by combining a DTN that uses short-range wireless with long-range wireless communication (Non-Patent Document 1, Patent Document 1).

[0005] The most common method for implementing DTN is to overlay an end-to-end message store-and-forward function called the bundle layer on top of conventional Internet protocol technology, and protocols for this purpose have been proposed. Protocol extensions have also been proposed to ensure security (confidentiality and integrity).

[0006] Several countermeasures have also been proposed against Denial of Service (DoS) attacks that wastefully use the bandwidth of DTN links and buffers of relay nodes (Non-Patent Document 2, Non-Patent Document 3).

[0007] 14 shows an example of a conventional wireless communication system 140. The network used in this example is a hybrid DTN that combines a DTN (Delay Tolerant Network) using short-range wireless communication with control by long-range wireless communication. The DTN using short-range wireless communication uses a data network 143, and the hybrid DTN that combines control by long-range wireless communication uses a control network 142.

[0008] An example of long-distance wireless communication is data communication via a cellular network. Examples of short-distance wireless communication include data communication using the wireless LAN-based IEEE802.11 (including, but not limited to, IEEE802.11p, which is specialized for vehicle-to-vehicle use) or C-V2X, a cellular-based derivative. Long-distance wireless communication is possible in many places but uses relatively low bandwidth, while short-distance wireless communication is possible only when mobile or fixed nodes are close to each other but uses relatively wide bandwidth. Furthermore, while long-distance wireless communication is often charged, short-distance wireless communication is either not charged or is relatively inexpensive. For this reason, in a Hybrid DTN, long-distance wireless communication is used for control, which involves relatively small amounts of information, and short-distance wireless communication is used for data collection, which involves relatively large amounts of information.

[0009] In a network, data sent from a sender is relayed by multiple nodes and received by the destination. In many networks, it is assumed that the communication links between nodes are generally always available. However, in a DTN, short-range wireless communication is used as the communication link between moving nodes, so situations often arise where other nodes that are the relay destinations are not within the range of short-range wireless communication, and it cannot be assumed that the links between nodes are always available. For this reason, nodes store data that has not yet been relayed in a buffer and forward it when they move and another node comes within the range of short-range wireless communication.

[0010] In many networks, the destination to which a node forwards data (assuming so-called unicast data with a single destination) is determined by the relay route at each instant, although the relay route may change dynamically during data forwarding. For this reason, the buffer space reserved for data relay can be released immediately after data forwarding. On the other hand, in DTN, there is no guarantee that a relay route from the data source to the destination exists at a given instant. In other words, it is assumed that no matter what relay route is used, the source and destination cannot be relayed using only the communication links available at that instant. Since it is not possible to determine a single appropriate node as the forwarding destination, a node usually forwards data to multiple nodes that become available for link connection while storing and moving the data. For this reason, the buffer space reserved for data relay is not released immediately after data forwarding, but is released when the data is confirmed to be delivered, a timeout, etc.

[0011] In a DTN, it takes time to release a buffer, and once there are no free buffers, it is no longer possible to accept any more data to be relayed, so relay nodes require a relatively large number of buffers. In a Hybrid DTN, as shown in Figure 14, a central control station 141 uses long-distance wireless communication to send a delivery status vector 147 containing data delivery confirmation information to each mobile node 144a-144d. In a Hybrid DTN, delivery confirmation information can be obtained via long-distance wireless communication, which is almost always available, so relay nodes can release buffer space that is no longer needed relatively quickly compared to a non-hybrid DTN. This makes it easier to effectively utilize buffer space, and reduces unnecessary data transmission after delivery, which has the advantage of less straining the capacity of the communication link. [Prior art documents] [Patent documents]

[0012] [Patent Document 1] Patent No. 7388784 [Non-patent literature]

[0013] [Non-Patent Document 1] Y. Teranishi, T. Kimata, E. Kawai and H. Harai,″Hybrid Cellular-DTN for Vehicle Volume Data Collection in Rural Areas,″2019 IEEE 43rd Annual Computer Software and Applications Conference (COMPSAC), Milwaukee, WI, USA, 2019, pp. 276-284, doi:10.1109 / COMPSAC. 2019.00048. [Non-patent document 2] V. Natarajan, Y. Yang and S. Zhu,″Resource-misuse attack detection in delay-tolerant networks,″30th IEEE International Performance Computing and Communications Conference, Orlando, FL, USA, 2011, pp. 1-8, doi: 10.1109 / PCCC. 2011.6108092. [Non-patent document 3] Q. Gao, W. Gao, S. Zhu and G. Cao,“To Comply: Defending against Flood Attacks in Disruption Tolerant Networks,”in IEEE Transactions on Dependable and Secure Computing, vol. 10, no. 3, pp. 168-182, May-June 2013, doi: 101109 / TDSC.2012.84. Summary of the Invention [Problem to be solved by the invention]

[0014] In the background section, we mentioned that it is necessary to secure free buffers at relay nodes in order for DTN to function. One possible DoS attack against DTN is to send a large amount of data to exhaust the free buffers. First, we need to develop countermeasures against such DoS attacks.

[0015] However, since long-distance wireless communication is available in Hybrid DTN, it can be used as a means of coordinating multiple attacking nodes to launch a Distributed Denial of Service (DDoS) attack. By exchanging various information, including cryptographic parameters, which are small in volume compared to the data itself, via long-distance wireless communication, it becomes possible to set up multiple attacking nodes in remote locations. Details of the attack method will be described later. If a DDoS attack is possible, multiple nodes will generate messages that are cryptographically indistinguishable from legitimate messages, making the message volume limit mentioned above ineffective. Measures to prevent such DDoS attacks are also necessary.

[0016] In order to put information gathering using Hybrid DTN into practical use, wireless communication devices, wireless communication management devices, and wireless communication systems that are resistant to such DoS attacks and DDoS attacks are required.

[0017] Therefore, the present invention has been devised in consideration of the above-mentioned problems, and its purpose is to provide a wireless communication device, a wireless communication management device, and a wireless communication system that can suppress DoS attacks against DTNs and also suppress DDoS attacks against DTNs. [Means for solving the problem]

[0018] In order to solve the above-mentioned problems, a wireless communication device according to a first aspect of the present invention is characterized by comprising: a token receiving means for receiving a server-signed secure token indicating restrictions on permission for a node to generate a message; a message generating means for generating a secure message consisting of the secure token received by the token means, generated data, and a node signature for the secure token and the generated data; and a wireless receiving means for receiving a secure message from another node, determining that the server signature of the secure token and the node signature of the secure message are genuine, and if it is determined that the secure message satisfies the restrictions of the secure token, recording a reception history and receiving the secure message, and discarding the secure message if it is determined that the secure message is not genuine or is a duplicate.

[0019] The wireless communication device according to the second invention is characterized in that, in the first invention, it comprises wireless transmission means which, when transmitting the secure message, determines whether the secure message was generated by the own node or another node, and, if it was generated by another node, allows transmission only if there is a reception history.

[0020] A wireless communication management device according to a third aspect of the present invention is characterized by comprising: a token generating means for generating a server-signed secure token indicating restrictions on message generation permission for a node; a token sending means for sending the secure token generated by the token generating means to a target node; and a delivery status sending means for receiving a secure message and, if it determines that the server signature of the secure token for the secure message and the node signature for the secure message are authentic, notifying each subordinate node that the secure message has been delivered.

[0021] A wireless communication system according to a fourth aspect of the present invention is characterized by comprising the wireless communication device according to the first aspect of the present invention or the wireless communication device according to the second aspect of the present invention, and the wireless communication management device according to the third aspect of the present invention. [Effects of the Invention]

[0022] According to the first to fourth inventions, it is possible to realize a wireless communication device, a wireless communication management device, and a wireless communication system that are capable of suppressing DoS attacks against the DTN and also capable of suppressing DDoS attacks against the DTN.

[0023] The central control station can use the secure tokens issued to each node to limit the amount of secure messages that each node can legitimately generate as needed. A relay node that receives a secure message stores and relays the message if it determines that the message is legitimate, and discards it if it is not.

[0024] Since the secure token is signed with the private key of the central control station, it is difficult for anyone other than the central control station to forge a secure token and increase the amount of secure messages that are permitted as valid.

[0025] A secure message contains the generated data and the secure token that authorized the generation of that message, and is signed with the private key of the generating node. This makes it difficult to attack by generating a legitimate secure message unless the private key of the generating node is known.

[0026] An attack is possible in which multiple remote attacking nodes share a secure token and a private key via long-distance wireless communication to increase the amount of legitimate secure messages. Furthermore, if multiple remote attacking nodes share data generation rules in advance, they can generate legitimate secure messages without sharing a private key by sending a secure token and a signature via long-distance wireless communication. Furthermore, by sending a hash of data generated by a remote node to an attacking node via long-distance wireless communication and receiving a corresponding signature and secure token, multiple remote nodes can generate legitimate secure messages without sharing a private key. Once these invalid secure messages sent by a remote attacking node are transmitted externally, they cannot be distinguished from legitimate, non-malicious secure messages that are relayed. Therefore, it is necessary to determine whether a message is invalid before it is transmitted, and a secure transmission function is added to the node's short-distance wireless communication function. If an invalid secure message is generated within the local node, the message contains a secure token and signature of another node, not the local node, and cannot be received externally. The secure transmission function keeps a record of receipt when a legitimate secure message is received, and for messages for which there is no receipt record, allows only messages generated by the node itself to be sent, and for messages for which there is a receipt record, allows relay transmission of messages generated by other nodes. [Brief explanation of the drawings]

[0027] [Figure 1] FIG. 1 is a schematic diagram illustrating an example of an outline of a wireless communication system according to an embodiment. [Figure 2] FIG. 2 is a diagram showing an example of the structure of a secure message used in the wireless communication system according to the embodiment. [Figure 3] FIG. 3 is a diagram illustrating an example of system operation during a DDoS attack by token / secret key distribution in remote wireless communication according to an embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of system operation when a DDoS attack occurs using a signature request in remote wireless communication according to the embodiment. [Figure 5]FIG. 5 is a diagram illustrating an example of a system operation when a DDoS attack occurs by sharing payload generation rules in remote wireless communication according to the embodiment. [Figure 6] FIG. 6 is a functional block diagram of a central control station in the wireless communication system according to the embodiment. [Figure 7] FIG. 7 is a functional block diagram of a public key infrastructure in the wireless communication system according to the embodiment. [Figure 8] FIG. 8 is a functional block diagram of a mobile node during a generating operation in the wireless communication system according to the embodiment. [Figure 9] FIG. 9 is a functional block diagram of a mobile node in a wireless communication system according to an embodiment, during relay operation and reception. [Figure 10] FIG. 10 is a functional block diagram of a mobile node in a wireless communication system according to an embodiment, during relay operation and transmission. [Figure 11] FIG. 11 is an operational flowchart illustrating an example of a message reception process in the wireless communication system according to the embodiment. [Figure 12] FIG. 12 is an operational flowchart illustrating an example of a message transmission process in the wireless communication system according to the embodiment. [Figure 13] FIG. 13 is a diagram illustrating an example of the contents and uses of a secure token / delivery status vector in a wireless communication system according to an embodiment. [Figure 14] FIG. 14 is a schematic diagram showing an example of an outline of a conventional wireless communication system. DETAILED DESCRIPTION OF THE INVENTION

[0028] <Embodiment> A wireless communication system 100 according to an embodiment of the present invention will be described in detail below. Fig. 1 is a schematic diagram showing an example of an overview of a wireless communication system 100 according to an embodiment of the present invention.

[0029] The wireless communication system 100 comprises a central control station 1, a public key infrastructure 2, a control network 3, a data network 4, mobile nodes 5a-5d, and a fixed node 6. The central control station 1 is network-connected to the public key infrastructure 2. The mobile nodes 5a-5d are connected to the control network 3 of the central control station 1 via long-distance wireless communication, and the fixed node 6 is connected to the central control station 1 via the control network 3 and data network 4. The connection between the central control station 1 and the fixed node 6 via the control network 3 and data network 4 may be wired or wireless. The mobile node 5a can communicate data with other mobile nodes 5b-5d or the fixed node 6 via short-distance wireless communication. Here, when a mobile node among the mobile nodes 5a-5d is to be represented, it is simply referred to as the mobile node 5. There may be multiple fixed nodes 6.

[0030] An example of long-distance wireless communication is data communication via a cellular network. Examples of short-distance wireless communication include data communication using wireless LAN-based IEEE802.11 (including, but not limited to, IEEE802.11p, which is specialized for vehicle-to-vehicle communication) or C-V2X, which is derived from cellular systems. Long-distance wireless communication is possible in many places but uses a relatively low bandwidth, while short-distance wireless communication is possible only when mobile nodes 5 or fixed nodes 6 are close to each other but uses a relatively wide bandwidth. Furthermore, long-distance wireless communication is often charged, while short-distance wireless communication is not charged or is relatively inexpensive. For this reason, it is conceivable to use long-distance wireless communication for control involving a relatively small amount of information, and short-distance wireless communication for data collection involving a relatively large amount of information, and the present invention distinguishes between them in this manner.

[0031] The central control station 1, the mobile nodes 5 and the fixed nodes 6 exchange control information (indicated by C in FIG. 1) via the control network 3. The control information includes a secure token 8 and a delivery status vector 9, which will be described later.

[0032] When deemed necessary, the central control station 1 generates a secure token 8 required for transmission of data generated by a specific mobile node 5 and transmits it to the mobile node 5 via the control network 3. The secure token 8 limits the amount of secure messages that can be legitimately generated. The secure token 8 may also limit the types of data that can be included in legitimately generated secure messages 7. The secure token 8 may also be used to instruct the mobile node 5 to collect data of a specified data type.

[0033] The mobile node 5 that receives the secure token 8 stores the generated data in the form of a secure message 7, which will be described later, and when it becomes able to communicate with another mobile node 5 or fixed node 6, transmits it to that other mobile node 5 or fixed node 6 using short-range wireless communication. Here, a secure message 7 that is determined to be valid using the method described later can be created within the range of data amount and data type allowed by the secure token 8 issued by the central control station 1. At this time, the mobile node 5 is said to be in the process of generating the message.

[0034] When a mobile node 5 receives a secure message 7, it follows the relay procedure described below, and if it determines that the received secure message 7 is legitimate, it stores the message and keeps a record of its receipt; otherwise, it discards it. When it becomes able to communicate with another mobile node 5 or fixed node 6, it transmits the secure message 7 stored in that other mobile node 5 or fixed node 6 using short-range wireless communication. At this time, the mobile node 5 is said to be in relay operation. When in relay operation, it transmits the secure message 7 generated by the other mobile node 5 or fixed node 6.

[0035] Furthermore, to prevent DDoS attacks carried out by multiple attackers working together using long-distance wireless communication, it is necessary to distinguish between a secure message 7 that has been forged within the node pretending to have been generated by another node and a legitimate secure message 7. For this reason, a secure transmission function is provided, and the transmission of a secure message 7 generated by another node is permitted only when the reception record of the secure message 7 (described above) is confirmed.

[0036] When the fixed node 6 receives the secure message 7, if it determines that the received secure message 7 is legitimate based on the relay procedure described below, it sends it to the central control station 1 via the data network 4, and if not, it discards it.

[0037] If the central control station 1 can confirm the authenticity of the received secure message 7, it accepts the data. If the authenticity cannot be confirmed, it discards the message. Information for understanding the status of an attack may be extracted from the discarded secure message 7. The central control station 1 creates a delivery status vector 9 indicating the data that has already been received at an appropriate frequency and sends it to the mobile node 5 via the control network 3. When the mobile node 5 or fixed node 6 receives the delivery status vector 9, if the central control station 1 has stored a secure message 7 corresponding to data that has already been received, it discards it.

[0038] FIG. 2 shows an example of a secure message construction procedure. A secure message (SM) 7 consists of a secure token (ST) 8, an encrypted payload (EP) 9, and a node signature (MAC) 10. Secure tokens 8a to 8c (hereinafter simply referred to as 8) consist of a server signature, a nonce to be signed, and a node public key. The nonce consists of the expiration date of the secure token 8, a node ID, and a sequence number. The uniqueness of the nonce is ensured by including the node ID and sequence number. Assuming that the central control station 1 and node 5 or 6 share a symmetric encryption key, the encrypted payloads 12 and 13 are obtained by encrypting a plaintext payload (PP) 11 and adding an appropriate initialization vector. However, encrypting the payload is not essential to achieving the object of the present invention, which is to prevent DoS attacks.

[0039] The outline of the present invention has been explained using an example of the outline of a wireless communication system 100 in Fig. 1 and an example of a secure message configuration in Fig. 2. When the wireless communication system 100 is configured in this manner, a secure message 7 containing data generated by each mobile node 5 is discarded even if received by another mobile node 5 if the data amount and data type exceed the data amount and data type indicated in the secure token 8 issued by the central control station 1. This makes it possible to suppress DoS attacks in which one mobile node 5 acts as an attacker and sends a large amount of data, causing the relay buffer of another mobile node 5 to overflow.

[0040] Up to the DoS attack described above, a secure transmission unit that distinguishes between a secure message forged in the own node pretending to have been generated by another node and a legitimate secure message and transmits only the latter is not necessarily required.

[0041] The DDoS attacks that are assumed to be suppressed by the Secure Transmission Unit are explained below. In all of the DDoS attack examples shown below, large payloads themselves are not sent between attacking nodes, but rather relatively small amounts of data are sent and received, so they could potentially be implemented with long-distance wireless communication. Here, whether or not the payload is concealed is not the essence of the discussion, so for simplicity's sake, we will not consider the concealment of the payload.

[0042] Figure 3 shows an example of a DDoS attack in which a token and a private key are distributed to attacking nodes that will serve as stepping stones. Prior to the attack, attacking nodes 15a, 15b, 15c, etc. (hereafter referred to as 15) are prepared as stepping stones in some way. In other words, attacking nodes 15a, 15b, and 15c are assumed to have been hacked in some way and have software used for the attack placed inside. When attacking node 14 receives a secure token 8 from central control station 1, attacking node 14 in possession of the token sends the secure token 8 and private key to attacking node 15 via long-distance wireless communication. Using the received secure token 8 and private key, attacking node 15 forges a secure message (with any payload) that is indistinguishable from a legitimate secure message (with a legitimate signature) and sends it to nodes with which it can communicate.

[0043] To prevent DDoS attacks, it is considered effective to hide the private key in a tamper-resistant secure module. Such a secure module typically has the function of inputting the hash of the object to be signed, calculating the corresponding signature using the private key, and outputting it.

[0044] Figure 4 shows an example of a DDoS attack in which a stepping-stone attack node 17 requests a signature from a token-possessing attack node 16. Prior to the attack, stepping-stone attack nodes 17a, 17b, 17c, etc. (hereafter referred to as 17) are prepared in some way. When the attack node 16 receives a secure token 8 from the central control station 1, the token-possessing attack node 16 sends the secure token 8 to the stepping-stone attack node 17 via long-distance wireless communication. The stepping-stone attack node 17 calculates a hash for the received secure token and an arbitrary payload, and requests the token-private key-possessing attack node 16 to sign the hash via long-distance wireless communication. The token-private key-possessing attack node 16 calculates a signature for the received hash and sends it back to the stepping-stone attack node 17 via long-distance wireless communication. This signature calculation cannot be prevented by the typical secure module described above. The attacking node 17, which acts as a springboard, uses the received signature to forge a secure message (consisting of the secure token that was the subject of the hash calculation, the payload, and the signature) that is indistinguishable from a legitimate secure message (the signature is legitimate), and sends it to a node with which it can communicate.

[0045] To prevent this DDoS attack, it would be effective for a tamper-resistant secure module to use the original data to be signed as input rather than a hash when calculating a signature. Alternatively, it would be effective to use a hash as input to the secure module, but limit access to the secure module to highly reliable software, which would calculate a hash from the original data and input it into the secure module to obtain a signature.

[0046] Figure 5 shows an example of a DDoS attack in which a payload generation rule is shared between attacking nodes 18 and 19. Prior to the attack, attacking nodes 19a, 19b, 19c, etc. (hereinafter referred to as 19) are prepared as stepping stones in some way, and the payload generation rule is shared between attacking nodes 18 and 19. The payload generation rule can be one that can generate large-sized payload data using small-sized parameters. For example, it can be one that simply uses the first and last values of an integer sequence such as n, n+1, n+2, etc. as parameters. When attacking node 18 receives a secure token 8 from the central control station 1, the attacking node 18 possessing the token determines appropriate parameter values to generate a payload, and calculates a signature for the secure token 8 and the generated payload using a private key. The attacking node 18 possessing the token sends the secure token, the parameter values used to generate the payload, and the signature to attacking node 19, which will serve as a stepping stone, via long-distance wireless communication. The attacking node 19, which acts as a springboard, generates a payload using the shared payload generation rules and the received parameter values, attaches the received secure token and signature to it, and forges a secure message that is indistinguishable from a legitimate secure message (the signature is legitimate), and sends it to a node with which it can communicate.

[0047] The DDoS attack by payload generation rule sharing described here cannot be prevented by the countermeasures described so far for DDoS attacks by token and private key distribution or DDoS attacks by signature requests. Because relay nodes transmitting messages generated by other nodes is a normal DTN operation that occurs even when there is no attacker present, it is difficult to distinguish between legitimate transmissions and transmissions by attacking nodes19 acting as springboards. To prevent DDoS attacks by payload generation rule sharing, each node must use short-range wireless communication to allow only relayed transmissions of secure messages with secure tokens issued to other nodes, and to prevent the transmission of secure messages forged by an attacker within the node itself. Specific methods for relay operation on the receiving and transmitting sides will be described later.

[0048] FIG. 6 shows a schematic block diagram of the central control station 1.

[0049] When issuing a secure token 8, the central control station 1 operates as follows. The data collection manager 20 determines the target mobile node 5, the type of data to be collected, the amount of data that is allowed to be collected, and the expiration date of the secure token. Here, the type of data to be collected may be limited to a specific data type, or it may be any data.

[0050] The secure token may be issued either by an autonomous decision of the central control station 1 or in response to a request from the mobile node 5 .

[0051] When issued by the autonomous decision of the central control station 1, the secure token 8 may also be considered to serve as a data collection instruction that instructs the mobile node 5 to collect specified data. The content of the instruction may not only be a simple data type such as temperature or camera images, but may also include various instructions regarding the data collection method, such as a combination of the time, place, and data type at which data should be collected. Hereinafter, the data collection method and the like will be referred to as the data type. The data type may be commonly defined for all nodes in the system.

[0052] If the public key of the target mobile node 5 is not cached in the central control station 1, the public key of the mobile node 5 is queried from the public key infrastructure 2, and the public key of the mobile node 5 is obtained from the response from the public key infrastructure 2.

[0053] The secure token issuing unit 21 signs (server signature) the public key of the mobile node 5, the nonce, the type of data to be collected, the amount of data allowed to be collected, and the expiration date of the secure token using the private key of the central control station 1, and generates a secure token.

[0054] Here, the nonce is generated so as to ensure that it is different for each secure token. For example, it may be composed of a mobile node identifier and a sequence number for each mobile node. If the type of data to be collected is predetermined, the type of data to be collected can be implicitly omitted. If a secure token is used as an instruction to collect specific data, an identifier of the data type that is commonly defined for the entire system may be explicitly included. Also, if the amount of data that is permitted to be collected is predetermined, the amount of data can be implicitly omitted. If the generation of multiple secure messages is permitted using a single secure token, the maximum number of secure message generations or the maximum data amount (number of bytes, etc.) may be included as part of the nonce. Also, if the validity period after the secure token is generated is predetermined, and the expiration date is not explicitly stated in the secure token, the generation time of the secure token may be included in the nonce.

[0055] The secure token issuing unit 21 transmits the generated secure token 8 to the target mobile node 5 via the control network 3 .

[0056] When receiving data, the central control station 1 operates as follows.

[0057] When the data receiving unit 22 receives data in the form of a secure message 7, it verifies the legitimacy of the secure message 7. It checks requirements such as whether the secure message 7 was sent by the mobile node 5 specified by the secure token 8, whether the type of data to be collected matches the type of data collected, whether the amount of data allowed to be collected is within the validity period of the secure token 8, whether the message has the same nonce and message number as a previously received secure message 7 but the payload contents are the same. Furthermore, it checks the server signature of the secure token 8 and the signature of the mobile node 5 for the entire secure message 7. This verifies legitimacy.

[0058] If the authenticity is verified, the data included in the secure message 7 is stored by the data storage unit 23. In addition, the data collection management unit 20 is notified of reception metadata required to identify the data that has been completely received. For example, the nonce included in the secure token of the secure message can be used as the reception metadata (information). If a single secure token allows the generation of multiple secure messages, the nonce and message number can be used as the reception metadata.

[0059] Secure messages whose authenticity cannot be verified are discarded. At this time, information for estimating the status of the attack may be extracted from the secure message. The central control station 1 may accumulate information on attacks or suspected attacks, and may take measures such as suspending the issuance of secure tokens to mobile nodes suspected of being the attackers, or invalidating secure tokens issued in the past.

[0060] When transmitting the delivery status, the central control station 1 operates as follows.

[0061] The data collection management unit 20 compiles the accumulated received metadata up to a certain extent in the past at an appropriate frequency and instructs the delivery status vector generation and transmission unit 24 to send the compiled received metadata in the form of a delivery status vector.

[0062] The delivery status vector generation and transmission unit 24 arranges multiple received metadata to create a delivery status vector, signs it with the private key of the central control station 1 to create a delivery status vector 9, and transmits it to each mobile node 5 via the control network 3.

[0063] The data collection management unit 20 may store and analyze historical information of received secure messages 7 in order to determine the amount and rate of data generation (amount generated per hour) permitted for each node by the secure token 8, the expiration date of the secure token, etc.

[0064] The data collection manager 20 may determine whether the purpose of a previous data collection instruction has been achieved. If the purpose of the data collection instruction has been achieved, the data collection can be terminated by including the data type identifier corresponding to the data collection instruction in the delivery status vector 9. By interpreting a data type identifier that is not combined with a specific mobile node identifier as targeting all mobile nodes, data collection corresponding to the data type identifier from all mobile nodes 5 can be terminated.

[0065] If the data collection management unit 20 determines that a certain mobile node 5 is an attacker, it can suppress the relaying of the secure message 7 generated by the mobile node 5 by including the nonce contained in the secure token 8 issued to the mobile node 5 or the identifier of the mobile node 5 in the delivery status vector 9.

[0066] FIG. 7 shows a schematic block diagram of the public key infrastructure 2.

[0067] In issuing a secure module for incorporation of a mobile node into the wireless communication system 100, the public key infrastructure 2 operates as follows.

[0068] The public key infrastructure management unit 25 specifies the identifier of the mobile node and instructs the private key / public key generation unit 26 to generate and distribute keys.

[0069] Private key / public key generation unit 26 generates a pair of private key and public key, and passes the mobile node identifier and private key to secure module setting unit 27, and the mobile node identifier and public key to public key search unit .

[0070] The secure module setting unit 27 sets the identifier and secret key of the mobile node in a tamper-resistant secure module, and passes it to the secure module distribution unit 29 .

[0071] The secure module distribution unit 29 distributes this to the distribution destination. The secure module 30 may be a hardware module or a software module, but it is assumed that it is sent to the distribution destination in a trusted manner and installed in the mobile node 5 at the distribution destination in a trusted manner.

[0072] When public key search unit 28 receives an external inquiry specifying the identifier of mobile node 5, it responds with the corresponding public key certificate. Also, when it receives an instruction from public key infrastructure management unit 25 to revoke or suspend a specific key, it places the corresponding public key in an invalid or suspended state.

[0073] An example of the secure message generation operation of the mobile node 5 will be described with reference to FIG.

[0074] The mobile node 5 b receives the secure token 8 distributed from the central control station 1 via the long-distance wireless communication unit 31 and passes it to the secure token management unit 32 .

[0075] The secure token management unit 32 extracts the expiration date, the type of data to be collected, and the amount of data that is permitted to be collected, from the secure token 8 , and passes them along with the secure token 8 to the information collection control unit 33 .

[0076] The information collection control unit 33 selects an appropriate information acquisition unit 34 depending on the type of data to be collected, sends it an information acquisition request, and receives a response including the requested data. Multiple pieces of data and multiple types of data may be acquired. The time position obtained from the time position acquisition unit 35 may be assigned as the time position of data acquisition. The data acquired in this way is formatted appropriately as a payload, and a check is made to see if it fits within the permitted data volume. If it fits, the created payload, secure token, and expiration date are passed to the secure message generation unit 36, and a command to generate a secure message is issued.

[0077] The secure message generation unit 36 calculates a hash value for the secure token and payload. If the payload needs to be kept confidential, the payload is encrypted before the hash calculation using a cryptographically appropriate method such as CBC (Cipher Block Chaining) or CTR (counter) using a shared key shared with the central control station 1 by a method not specified here. The secure message generation unit 36 passes the hash value and secure token to the secure module and requests the generation of a node signature. If the secure token allows the generation of multiple secure messages using a single secure token, the secure message includes a message number or total number of bytes that are initialized for each secure token. The message number and total number of bytes are not included in the confidentiality range but are subject to the node signature.

[0078] The secure module 37 checks the authenticity of the server signature included in the secure token 8 and checks the expiration date of the token. If the time obtained from the time and position acquisition unit 35 is within the expiration date, it returns the node signature for the received hash to the secure message generation unit 36, and if not, it returns an expired error.

[0079] Upon receiving the node signature, the secure message generator 36 combines the secure token, payload, and node signature into a secure message, and passes it to the message buffer 38 .

[0080] In a DTN, there is not always a destination node to which a secure message can be sent via the short-range wireless communication unit 39, so the secure message is stored for a while in the message storage unit 38. When the long-range wireless communication unit 31 receives a delivery status vector 9 from the central control station 1, a discard instruction is passed to the message storage unit 38 via the delivery status management unit 40, and the secure message 7 indicated as delivered is discarded. If the delivery status vector 9 contains a data type identifier that is not combined with a specific mobile node identifier, the correspondence between the mobile nodes 5 is ignored and the message is considered to have been delivered if the data type identifier matches. If a specific mobile node identifier is included alone (for example, not combined with a sequence number, etc.), all secure messages generated by that mobile node are considered to have been delivered. The message may also be discarded due to a timeout.

[0081] To search for a partner node to which a secure message can be sent via the short-range wireless communication unit 39, the data communication control unit 41 uses the short-range wireless communication unit 39 to send a search packet at an appropriate frequency. If there is a response from another node, it means that a partner node to which a secure message can be sent via the short-range wireless communication unit 39 has been found. In this procedure, it is confirmed whether the short-range wireless communication unit 39 of the partner node is authentic. For example, appropriate mutual authentication is performed on the assumption that the short-range wireless communication unit 39 of each node is managed using a public key infrastructure 2 or the like.

[0082] When a partner node having a genuine short-range wireless communication unit 39 is found, the data communication control unit 41 passes the secure message stored in the message storage unit 38 to the short-range wireless communication unit 39 and requests transmission.

[0083] Upon receiving the transmission request, the short-range wireless communication unit 39 requests the node identification unit 42 to identify whether the node that generated the received secure message is its own node or another node, and receives a response. Here, it is assumed that the secure message was generated earlier, and the response received indicates that the message was generated by its own node. In this case, the short-range wireless communication unit 39 verifies the server signature of the secure token of the secure message and the node signature of the secure message, and then transmits the secure message.

[0084] Since the functionality relies on the authentic operation of the short-range wireless communication unit 39, node identification unit 42, and reception history recording unit 43, it is preferable that these functions be implemented in a manner that is less susceptible to attack than ordinary applications or operating systems.

[0085] An example of the secure message relay operation and reception by the mobile node 5 will be described with reference to FIG.

[0086] When the short-distance wireless unit 39 receives the above-mentioned search packet, it transfers it to the data communication control unit 41 .

[0087] The data communication control unit 41 uses the method described above to verify whether the short-range wireless communication unit 39 of the other node is authentic.

[0088] When a secure message is received from a partner node having a genuine short-range wireless communication unit 39, the short-range wireless communication unit 39 checks whether the secure message satisfies the expiration date and data volume constraints of the secure token, and discards it if it does not. Next, it calculates the hash of the secure message and checks whether there is any reception history with the same hash value in the reception history recording unit 43. If there is, it is determined to be a duplicate reception and discards it. The server signature of the secure token and the node signature of the secure message are checked, and if they are invalid, they are discarded. The reception history is registered in the reception history recording unit 43 using the hash value calculated earlier. The short-range wireless communication unit 39 passes the secure message to the data communication control unit 41.

[0089] The data communication control unit 41 inquires with the delivery status management unit 40 whether the secure message has been delivered, and if it has been delivered, it discards the message. If it has not been delivered, the secure message is stored in the message storage unit 38.

[0090] When the long-distance wireless communication unit 39 receives a delivery status vector 9 from the central control station 1, the secure message 7 indicated as delivered therein is discarded from the message storage unit 38. If the delivery status vector 9 contains a data type identifier that is not combined with a specific mobile node identifier, the corresponding relationship of the mobile node 5 is ignored and the message is considered to have been delivered if the data type identifier matches. If a specific mobile node identifier is included alone (e.g., not combined with a sequence number, etc.), all secure messages 7 generated by that mobile node 5 are considered to have been delivered. Messages may also be discarded due to a timeout.

[0091] An example of a secure message relay operation and transmission by the mobile node 5 will be described with reference to FIG.

[0092] In order to search for a partner node to which the secure message 7 can be transmitted by the short-distance wireless communication unit 39, the same method as that explained in the generation operation is used.

[0093] When a partner node having a genuine short-range wireless communication unit 39 is found, the data communication control unit 41 passes the secure message 7 stored in the message storage unit 38 to the short-range wireless communication unit 39 and requests transmission.

[0094] Upon receiving the transmission request, the short-range wireless communication unit 39 requests the node identification unit 42 to identify whether the node that generated the received secure message 7 is its own node or another node, and receives a response. Here, it is assumed that the secure message 7 was received earlier, and the response received indicates that it was generated by another node. In this case, the short-range wireless communication unit 39 calculates the hash value of the secure message 7 and checks the reception history recording unit 43 for the presence or absence of a reception history for the secure message 7. If a reception history is found, it is determined to be a relay transmission operation for a genuine secure message 7, and the unit 39 checks the server signature of the secure token and the node signature of the secure message before transmitting the secure message. If no reception history is found, it is determined to be a secure message forged by the own node pretending to have been generated by another node, and therefore discards the secure message.

[0095] Furthermore, because reception history is kept only for secure messages 7, protocols that require communication only between nodes within the range of short-range wireless communication and do not require relaying can be used relatively freely. In other words, even if reception of these protocols that are not cryptographically protected is permitted, it does not consume buffer space and is not further relayed, so it is thought that resistance to DoS attacks and DDoS attacks will not be reduced. Within this range of conditions, existing protocols can be used.

[0096] Some of the procedures described above are summarized in flowcharts shown as a message reception processing example in Figure 11 and a message transmission processing example in Figure 12. Although this has already been explained and will not be described in detail, the message transmission example is a procedure that integrates the generation operation and the relay operation and transmission.

[0097] An example of how to use the secure token and delivery status vector outlined above in accordance with their contents will be described in more detail with reference to FIG.

[0098] Consider the case where the nonce of a secure token is the sequence "expiration date - node ID - sequence number." In order to normally terminate data collection and corresponding secure message relay operations by this secure token, include "expiration date - node ID - sequence number" as received metadata in the delivery status vector. If an attack by the mobile node specified by the node ID is suspected, include "node ID" as received metadata in the delivery status vector to collectively stop all data collection and corresponding secure message relay operations by the mobile node specified by the node ID, not just the secure token with "expiration date - node ID - sequence number."

[0099] Consider the case where the nonce of a secure token is the sequence of "issue date and time - node ID - data type - data amount." To normally terminate data collection and secure message relay operations using this secure token, include "issue date and time - node ID - data type" as received metadata in the delivery status vector. The data amount included in the nonce may be omitted. To terminate data collection and corresponding secure message relay operations instructed before the issue date and time of the data type for all nodes, include "issue date and time - data type" as received metadata in the delivery status vector. If an attack by the mobile node specified by the node ID is suspected, include "node ID" as received metadata in the delivery status vector to collectively terminate all data collection and corresponding secure message relay operations by the mobile node specified by the node ID, not just the secure token with "issue date and time - node ID - data type - data amount."

[0100] In the above example, the bit string (or information element) of the received metadata in the delivery status vector will differ from the bit string (information element) of the nonce included in the secure token, but since the secure token and delivery status vector are signed by the server of the central control station, as long as the authenticity of the server signature can be confirmed, mobile nodes and fixed nodes may treat the bit string (information element) of the received metadata as authentic. By limiting the range of instructions to the specified part of the bit string (information element) of the received metadata and treating the rest as unrestricted, the central control station can issue collective instructions using a short delivery status vector.

[0101] <Examples of use in which the effects of the invention are most effectively demonstrated> According to the present invention, it is possible to suppress DoS attacks in which an attacker sends a large amount of data to a DTN, exhausting the buffers of relay nodes. Furthermore, according to the present invention, it is possible to suppress DDoS attacks in which multiple remote attackers cooperate with each other using long-distance communication. This is expected to be particularly effective in suppressing DoS and DDoS attacks against a hybrid DTN. [Explanation of symbols]

[0102] 1 Central Control Station 2 Public Key Infrastructure 3 Control Network 4. Data Network 5, 5a, 5b, 5c, 5d··· Mobile node 6 Fixed Nodes 7. Secure Messages 8, 8a, 8b, 8c... Secure Token 9 Delivery Status Vector 10 Node Signature 11 Plaintext Payload (PP) 12, 13 Encrypted Payload (EP) 14 attacking nodes (token owners) 15, 15a, 15b, 15c, ... Attacker node (springboard) 17, 17a, 17b, 17c, ... Attacker node (springboard) 19, 19a, 19b, 19c, ... Attacker node (springboard) 16 attacking nodes (token and private key holders) 18 attacking nodes (token and private key holders) 20 Data Collection Management Department 21 Secure Token Issuance Department 22 Data receiving unit 23 Data Storage Unit 24 Delivery status vector generation and transmission unit 25 Public Infrastructure Management Department 26 Private key and public key generation unit 27 Secure module setting section 28 Public Key Search Unit 29 Secure Module Distribution Department 30 Secure Module 31 Long-distance wireless communication department 32 Secure Token Management Department 33 Information Collection and Control Unit 34 Information Acquisition Department 35 Time position acquisition section 36 Secure Message Generation Unit 37 Secure Module 38 Message storage unit 39 Near Field Wireless Communication Department 40 Delivery Status Management Department 41 Data communication control section 42 Node Identification Unit 43 Reception history recording section 100 Wireless Communication System 110 Message Receiving Step 111 Token Constraint Validation Step 112 Duplicate Receipt Confirmation Step 113 Token / Server Signature Verification Step 114 Message / Node Signature Verification Step 115 Message Disposal Step 116 Reception history registration step 117 Message Storage Step 120 Message Input Step 121 Origin Determination Step 122 Receiving record confirmation step 123 Token / Server Signature Verification Step 124 Message / Node Signature Verification Steps 125 Message Disposal Step 126 Message sending step

Claims

1. token receiving means for receiving a server-signed secure token indicating constraints on which nodes are permitted to generate messages; a message generating means for generating a secure message including the secure token received by the token means, generated data, and a node signature for the secure token and the generated data; a wireless receiving means for receiving a secure message from another node, determining that the server signature of the secure token of the secure message and the node signature of the secure message are authentic, and if it is determined that the secure message satisfies the constraints of the secure token, recording a reception history and receiving the secure message, and discarding the secure message if it is determined that the secure message is not authentic or is a duplicate; A wireless communication device comprising:

2. a wireless transmission means for determining whether the secure message was generated by the node itself or another node when transmitting the secure message, and permitting transmission only if the secure message was generated by another node and has a reception history; 2. The wireless communication device of claim 1, further comprising:

3. token generation means for generating a server-signed secure token indicating constraints on which nodes are allowed to generate messages; a token transmission means for transmitting the secure token generated by the token generation means to a target node; a delivery status sending means for receiving a secure message and, when determining that the server signature of the secure token of the secure message and the node signature of the secure message are authentic, notifying each subordinate node that the secure message has been delivered; A wireless communication management device comprising:

4. The wireless communication device according to claim 1 or The wireless communication device according to claim 2, and the wireless communication management device according to claim 3, A wireless communication system comprising:

Images