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

Abstract

[Problem] To provide a wireless communication device, a wireless communication management device, and a 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 comprising: a token receiving means for receiving a server-signed secure token indicating constraints for when a node is permitted to generate a message; a message generating means for generating a secure message comprising the secure token received by the token means, generated data that have been generated, 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, 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 the 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.

Description

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

[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.

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

[0003] Conventional Internet technology relies on the premise 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 and 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 Delay and Disruption Tolerant Network (DTN) technology. A method has been proposed for communication between mobile devices such as automobiles, in which 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, Hybrid DTN has been proposed, which solves this trade-off by combining DTN, which uses short-range wireless communication, 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 a protocol for this purpose has been proposed. Protocol extensions to ensure security (confidentiality and integrity) have also been proposed.

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

[0007] 14 shows an example of a conventional wireless communication system 140. The network used in this example is a hybrid DTN (Delay Tolerant Network) that combines a DTN using short-range wireless communication with control by long-range wireless communication. The DTN using short-range wireless communication uses a data network 143, while the hybrid DTN combined with 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 wireless LAN-based IEEE 802.11 (including, but not limited to, IEEE 802.11p, which is specialized for vehicle-to-vehicle communication) or C-V2X, a cellular-based derivative. 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 or fixed nodes are close to each other but uses a relatively wide bandwidth. Furthermore, while long-distance wireless communication is often charged, short-distance wireless communication is not charged or is relatively inexpensive. For this reason, in Hybrid DTN, long-distance wireless communication is used for control, which involves a relatively small amount of information, and short-distance wireless communication is used for data collection, which involves a relatively large amount of information.

[0009] In a network, data transmitted from a sender is relayed by multiple nodes and received by a 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, and situations often arise where other nodes to which data is to be relayed are not within the reach of short-range wireless communication, making it impossible to assume that the links between nodes are always available. For this reason, a node stores data that has not yet been relayed in a buffer and transfers it when it moves and another node comes within the reach 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 transfer. Therefore, the buffer space reserved for data relay can be immediately released after data transfer. On the other hand, in DTN, a relay route from the data sender to the destination may not exist 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 destination, a node typically forwards data to multiple nodes that become available for link connection while storing and transferring the data. Therefore, the buffer space reserved for data relay is not immediately released after data transfer, but is released upon confirmation of delivery of the data, timeout, etc.

[0011] In a DTN, it takes time to release a buffer, and once there are no free buffers, the relay node cannot accept any more data to be relayed, so a relatively large number of buffers are required. In a Hybrid DTN, as shown in FIG. 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 is obtained via long-distance wireless communication, which is generally always available. Therefore, compared to a non-Hybrid DTN, a relay node can release unnecessary buffer space relatively quickly. This makes it easier to effectively utilize buffer space, and reduces unnecessary data transmission after delivery, which minimizes strain on the communication link capacity.

[0012] Patent No. 7388784

[0013] 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.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.Q. 2013, doi: 101109 / TDSC.2012.84.

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

[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 described above ineffective. Measures to prevent such DDoS attacks are also necessary.

[0016] To put information collection using Hybrid DTN into practical use, a wireless communication device, a wireless communication management device, and a wireless communication system 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 are capable of suppressing DoS attacks against DTN and also capable of suppressing DDoS attacks against DTN.

[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 the secure message 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 permission for a node to generate a message; 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.

[0022] According to the first to fourth aspects of the present invention, 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.

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

[0028] <Embodiment> A wireless communication system 100 according to an embodiment of the present invention will now be described in detail. 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 to 5d, and a fixed node 6. The central control station 1 is network-connected to the public key infrastructure 2. The mobile nodes 5a to 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 the data network 4. The connection between the central control station 1 and the fixed node 6 via the control network 3 and the data network 4 may be wired or wireless. The mobile node 5a can communicate data with other mobile nodes 5b to 5d or the fixed node 6 via short-distance wireless communication. Here, when a mobile node is represented among the mobile nodes 5a to 5d, 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 IEEE 802.11 (including, but not limited to, IEEE 802.11p, which is specialized for vehicle-to-vehicle communication) or C-V2X, a cellular-based derivative. 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, while long-distance wireless communication is often charged, 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 the secure token 8 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 the data to the other mobile node 5 or fixed node 6 using short-range wireless communication. 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 a 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 the message. When it becomes capable of communicating 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 a secure message 7 generated by the other mobile node 5 or fixed node 6.

[0035] Furthermore, in order 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 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 the plaintext payload (PP) 11 and adding an appropriate initialization vector. However, encrypting the payload is not essential to achieving the objective of the present invention, which is to prevent DoS attacks.

[0039] The outline of the present invention has been explained using the outline example of wireless communication system 100 in Fig. 1 and the secure message configuration example in Fig. 2. When 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 those 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 be generated by another node and a legitimate secure message and transmits only the latter is not necessarily required.

[0041] The DDoS attacks assumed to be suppressed by the secure transmission unit are described below. In all of the DDoS attack examples shown below, large payloads themselves are not the target of transmission between attacking nodes, but rather relatively small data, so they may be feasible if long-distance wireless communication is available. Here, whether or not the payload is concealed is not the essence of the discussion, so for simplicity of explanation, we will not consider the concealment of the payload.

[0042] 3 shows an example of a DDoS attack in which a token and a private key are distributed to attacking nodes that will act as stepping stones. Prior to the attack, attacking nodes 15a, 15b, 15c, etc. (hereinafter, collectively 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 illegally hacked in some way, with software used for the attack placed inside. When attacking node 14 receives a secure token 8 from central control station 1, the token-possessing attacking node 14 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 transmits 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] 4 shows an example of a DDoS attack in which a springboard attacking node 17 requests a signature from a token-possessing attacking node 16. Prior to the attack, springboard attacking nodes 17a, 17b, 17c, etc. (hereinafter, collectively referred to as 17) are prepared in some way. When the attacking node 16 receives a secure token 8 from the central control station 1, the token-possessing attacking node 16 sends the secure token 8 to the springboard attacking node 17 via long-distance wireless communication. The springboard attacking node 17 calculates a hash for the received secure token and an arbitrary payload, and requests the token- and private key-possessing attacking node 16 to sign the hash via long-distance wireless communication. The token- and private key-possessing attacking node 16 calculates a signature for the received hash and sends it back to the springboard attacking 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, a payload, and a 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 is considered 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 is also considered effective to use a hash as input to the secure module, but limit access to the secure module to highly reliable software, which can 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, ... (hereinafter, collectively 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 may be one that can generate large-sized payload data using small-sized parameters, such as a simple rule that uses the first and last values ​​of an integer sequence such as n, n+1, n+2, ... 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 the attacking node 19 that will serve as the stepping stone via long-distance wireless communication. The attacking node 19 that 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 based on payload generation rule sharing shown here cannot be prevented by the countermeasures described above for DDoS attacks based on token / secret key distribution and DDoS attacks based on signature requests. Because relay nodes transmitting messages generated by other nodes is a normal DTN operation that occurs even when an attacker is not present, it is difficult to distinguish between legitimate transmissions and transmissions by attacking nodes 19 acting as springboards. To prevent DDoS attacks based on payload generation rule sharing, each node performs short-range wireless communication by only allowing relay transmissions of secure messages with secure tokens issued to other nodes, and not allowing transmission of secure messages forged by an attacker within the node itself. Specific methods are described later for relay operation on the receiving and transmitting sides.

[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 permitted 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 by 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 include not only a simple data type such as temperature or camera image, but also 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. Note that 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 a specific data collection instruction, an identifier of the data type commonly defined for the entire system may be explicitly included. Also, if the amount of data 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 (e.g., number of bytes) may be included as part of the nonce. Also, the validity period after the secure token is generated may be predetermined, and instead of explicitly indicating the expiration date on 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 for collection 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, a 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 related to attacks or suspected attacks, and may stop issuing secure tokens to mobile nodes suspected of being the attackers, invalidate secure tokens issued in the past, etc.

[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 retain 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 into a mobile node in 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] The 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 the secure module setting unit 27, and the mobile node identifier and public key to the public key search unit 28.

[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. Furthermore, 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 permitted to be collected, contained in 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 or 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 secure message generation instruction 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 (couter) 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 node signature generation. If the secure token allows multiple secure messages to be generated using a single secure token, the secure message includes a message number or total byte count that is initialized for each secure token. The message number and total byte count 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, the secure module 37 returns the node signature for the received hash to the secure message generation unit 36; otherwise, it returns an expired error.

[0079] Upon receiving the node signature, the secure message generation unit 36 ​​combines the secure token, payload, and node signature into a secure message, and passes the message to the message storage unit 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 corresponds. If a specific mobile node identifier is included alone (e.g., 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 confirm 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. A reception history is registered in the reception history recording unit 43 using the previously calculated hash value. 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 of the delivery status management unit 40 whether the secure message has been delivered, and if it has been delivered, it discards it. 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 corresponds. 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] To search for a partner node to which the secure message 7 can be transmitted by the short-range 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 the secure message 7 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 server signature of the secure token and the node signature of the secure message are verified before transmitting the secure message. If no reception history is found, it is determined to be a secure message forged by the own node under the guise of being generated by another node, and the secure message is discarded.

[0095] Furthermore, because reception history is kept only for secure messages 7, protocols that require communication only between nodes within the reach 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, buffer space is not consumed and no further relay transmission is performed, 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 Fig. 11 and a message transmission processing example in Fig. 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 above-mentioned secure token and delivery status vector in accordance with their contents will be described in more detail with reference to FIG.

[0098] Consider a case where the nonce of a secure token is a sequence of "expiration date - node ID - sequence number." In order to normally terminate data collection and corresponding secure message relay operations by this secure token, "expiration date - node ID - sequence number" is included as reception metadata in the delivery status vector. If an attack by the mobile node specified by the node ID is suspected, "node ID" is included as reception metadata in the delivery status vector in order 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 a case where the nonce of a secure token uses the sequence "issue date and time-node ID-data type-data amount." In order to normally terminate data collection and secure message relay operations using this secure token, "issue date and time-node ID-data type" is included as reception metadata in the delivery status vector. The data amount included in the nonce may be omitted. In order to terminate data collection and corresponding secure message relay operations instructed before the issue date and time of the data type for all nodes, "issue date and time-data type" is included as reception metadata in the delivery status vector. If an attack by the mobile node specified by the node ID is suspected, "node ID" is included as reception metadata in the delivery status vector in order 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 "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, the mobile node and fixed node may treat the bit string (information element) of the received metadata as authentic.By limiting the range of instructions to the explicitly specified part of the bit string (information element) of the received metadata and treating the rest as unrestricted, the central control station can issue comprehensive instructions using a short delivery status vector.

[0101] <Example of use in which the effects of the invention are most effectively utilized> The present invention can suppress DoS attacks in which an attacker sends a large amount of data to a DTN, exhausting the buffers of relay nodes. The present invention can also suppress DDoS attacks in which multiple remote attackers cooperate with each other using long-distance communications to launch DDoS attacks against a DTN. This is expected to be particularly effective in suppressing DoS and DDoS attacks against a Hybrid DTN.

[0102] REFERENCE SIGNS LIST 1 Central control station 2 Public key infrastructure 3 Control network 4 Data network 5, 5a, 5b, 5c, 5d... Mobile node 6 Fixed node 7 Secure message 8, 8a, 8b, 8c... Secure token 9 Delivery state vector 10 Node signature 11 Plaintext payload (PP) 12, 13 Encrypted payload (EP) 14 Attacker node (token holder) 15, 15a, 15b, 15c... Attacker node (springboard) 17, 17a, 17b, 17c... Attacker node (springboard) 19, 19a, 19b, 19c... Attacker node (springboard) 16 Attacker node (token and private key holder) 18 Attacker node (token and private key holder) 20 Data collection management unit 21 Secure token issuing unit 22 Data receiving unit 23 Data storage unit 24 Delivery state vector generation and transmission unit 25 Public infrastructure management unit 26 Private key / public key generation unit 27 Secure module setting unit 28 Public key search unit 29 Secure module distribution unit 30 Secure module 31 Long-distance wireless communication unit 32 Secure token management unit 33 Information collection control unit 34 Information acquisition unit 35 Time and location acquisition unit 36 ​​Secure message generation unit 37 Secure module 38 Message storage unit 39 Short-distance wireless communication unit 40 Delivery status management unit 41 Data communication control unit 42 Node identification unit 43 Reception history recording unit 100 Wireless communication system 110 Message reception step 111 Token constraint validity confirmation step 112 Duplicate reception confirmation step 113 Token / server signature confirmation step 114 Message / node signature confirmation step 115 Message discarding step 116 Reception history registration step 117 Message storage step 120 Message input step 121 Generator determination step 122 Reception record confirmation step 123 Token / server signature verification step 124 Message / node signature verification step 125 Message discard step 126 Message transmission step

Claims

1. Token receiving means for receiving a server-signed secure token indicating constraints when permitting a node to generate a message; message generating means for generating a secure message comprising the secure token received by the token means, generated generated data, and a node signature for the secure token and the generated data; 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 genuine, and determining that the secure message satisfies the constraints of the secure token, and recording the reception history and receiving it, and discarding the secure message if it is determined to be non-genuine or duplicate. A wireless communication device characterized by comprising:

2. Wireless transmission means for determining whether a secure message is generated by its own node or another node when transmitting the secure message, and permitting transmission only when there is a reception history in the case of being generated by another node. The wireless communication device according to claim 1, characterized by comprising:

3. Token generation means for generating a server-signed secure token indicating constraints when permitting a node to generate a message; token transmission means for sending the secure token generated by the token generation means to a target node; secure message reception means, and when it is determined that the server signature of the secure token of the secure message and the node signature of the secure message are genuine, delivery status transmission means for notifying each node under its jurisdiction that the secure message has been delivered. A wireless communication management device characterized by 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 characterized by comprising:

Images