Data transmission method, communication processing method, apparatus, and communication processing program

The data transmission method using P2P and proxy servers with authenticated IP addresses addresses security challenges in network communication, ensuring secure and efficient data exchange with devices lacking encrypted capabilities.

JP2026021501APending Publication Date: 2026-02-10帝都久利寿 +1
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2025186430
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2025-11-05
Publication Date
2026-02-10

AI Technical Summary

Technical Problem

Existing network systems face challenges in maintaining security levels when communicating with devices that only have normal IP addresses, as they lack authenticated IP addresses.

Method used

A data transmission method using peer-to-peer (P2P) communication to generate and transfer encrypted packets between devices, with proxy servers handling communication with devices incapable of encrypted packet exchange, and a communication processing method to determine device capabilities and authenticate IP addresses using public keys and electronic certificates.

Benefits of technology

Maintains security levels while ensuring seamless communication with devices that cannot exchange encrypted packets, enhancing processing affinity and user convenience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2026021501000001_ABST
    Figure 2026021501000001_ABST
Patent Text Reader

Abstract

To provide one solution in a network in which a destination device includes a device incapable of exchanging encrypted packets.SOLUTION: A data transmission method according to an aspect of the present disclosure includes generating, in a first device, a first encrypted packet addressed to a second device, transferring the first encrypted packet from the first device to the second device by P2P, and generating, in the first device, a second encrypted packet addressed to a third device that serves as a proxy server of the first device. The second encrypted packets include packets destined for the fourth device. The method includes the steps of transferring the second encrypted packet from the first to third devices P2P, and transmitting a normal packet generated by decrypting the second encrypted packet in the third devices to the fourth devices.SELECTED DRAWING: Figure 10
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present disclosure relates to data communication techniques for devices with authenticated IP addresses. [Background technology]

[0002] Recent Information and Communication Technology Advances in ICT (Information and Communication Technology) have been remarkable, and devices connected to networks such as the Internet are no longer limited to traditional information processing devices such as personal computers and smartphones, but are now expanding to include a wide variety of things. This technological trend is known as the "Internet of Things" (IoT), and various technologies and services are being proposed and put into practical use. In the future, it is expected that billions of people and tens of billions or even trillions of devices on Earth will be connected simultaneously. To realize such a networked world, it is necessary to provide solutions that enable simpler, safer, and more free connections.

[0003] Typically, data communication between devices on a network is achieved using an Internet Protocol (IP) address that is statically or dynamically assigned to each device. For example, Japanese Patent Application Laid-Open Publication No. 2018-207472 (Patent Document 1) discloses a network system that uses a new concept of authenticating the network address itself. This network system enables secure communication between devices using authenticated IP addresses. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2018-207472 Summary of the Invention [Problem to be solved by the invention]

[0005] According to Patent Document 1, if the concept of achieving secure communication using such authenticated IP addresses is applied to an existing network, devices will need to communicate not only with devices that have authenticated IP addresses, but also with devices that only have normal IP addresses (i.e., the assigned IP addresses are not authenticated).

[0006] The present disclosure provides a solution in a network including devices with which the destination device is not capable of exchanging encrypted packets. [Means for solving the problem]

[0007] According to one embodiment of the present disclosure, there is provided a data transmission method in a network to which multiple devices are connected. The data transmission method includes the steps of: generating, in a first device, a first encrypted packet addressed to a second device; transferring the first encrypted packet from the first device to the second device via P2P (peer to peer); and generating, in the first device, a second encrypted packet addressed to a third device that serves as a proxy server for the first device. The second encrypted packet includes a packet addressed to a fourth device. The data transmission method includes the steps of transferring, in the third device via P2P, the second encrypted packet from the first device to the third device; and transmitting, in the third device, a normal packet generated by decrypting the second encrypted packet to the fourth device.

[0008] The data transmission method may further include, at the third device, receiving the response packet from the fourth device and generating a third encrypted packet addressed to the first device. The third encrypted packet may include the response packet. The data transmission method may further include transferring the third encrypted packet from the third device to the first device via P2P.

[0009] The data transmission method may further include transmitting a request from the first device to the third device to enable proxy operation.

[0010] The data transmission method may further include a step in which each of the first device, the second device, and the third device transmits a public key and an electronic certificate associated with the public key to another device, and a step in which, in the device receiving the public key and the electronic certificate, determines an IP address of the device that transmitted the public key and the electronic certificate based on a hash value calculated from the public key according to a hash function.

[0011] According to another aspect of the present disclosure, there is provided a communication processing method in a device connected to a network, the communication processing method including the steps of: determining, in response to a packet transmission request, whether a destination device is capable of exchanging encrypted packets; generating a first encrypted packet addressed to the destination device in accordance with the packet transmission request if the destination device is capable of exchanging encrypted packets; and forwarding the first encrypted packet to the destination device via P2P; and, if the destination device is not capable of exchanging encrypted packets, generating a second encrypted packet including a packet addressed to the destination device in accordance with the packet transmission request; and forwarding the second encrypted packet to a device serving as a proxy server via P2P.

[0012] The communication processing method may further include the steps of identifying a device to be a proxy server, and transmitting a request to enable proxy operation to the identified device.

[0013] The communication processing method may further include the steps of obtaining a private key and a public key, determining an IP address of the device based on a hash value calculated from the public key according to a hash function, obtaining an electronic certificate associated with the public key from a certification authority connected to the network, and transmitting the public key and the electronic certificate to another device.

[0014] The communication processing method may further include a step of determining the validity of the electronic certificate when a public key and an electronic certificate associated with the public key are received from another device, and a step of determining the IP address of the other device based on a hash value calculated from the public key according to a hash function when the electronic certificate is determined to be valid.

[0015] An apparatus according to yet another aspect of the present disclosure includes a network interface for connecting to a network, and a control unit connected to the network interface. The control unit performs the following operations: determining whether a destination device can exchange encrypted packets in response to a packet transmission request; generating a first encrypted packet for the destination device in accordance with the packet transmission request if the destination device can exchange encrypted packets; transferring the first encrypted packet to the destination device by P2P; generating a second encrypted packet including a packet for the destination device in accordance with the packet transmission request if the destination device can exchange encrypted packets; The device is configured to be able to execute a process of forwarding packets to a device that serves as a proxy server via P2P.

[0016] According to yet another aspect of the present disclosure, there is provided a communication processing program for a computer having a network interface for connecting to a network, the communication processing program causing the computer to perform the above-described communication processing method when executed by the computer. [Effects of the Invention]

[0017] According to the present disclosure, even in a network including a destination device that is not capable of exchanging encrypted packets, it is possible to maintain a security level while maintaining processing affinity. [Brief explanation of the drawings]

[0018] [Figure 1] 1 is a schematic diagram showing an example of an overall configuration of a network system according to an embodiment of the present invention; [Figure 2] FIG. 2 is a schematic diagram illustrating an example of a hardware configuration of a device according to the present embodiment. [Figure 3] FIG. 2 is a schematic diagram showing an example of a configuration of programs and data of a device according to the present embodiment. [Figure 4] FIG. 10 is a diagram illustrating an IP address authentication procedure in the network system according to the present embodiment. [Figure 5] FIG. 10 is a diagram showing an example of type specifying information embedded in an IP address used in the network system according to the present embodiment. [Figure 6] 10 is a flowchart showing a processing procedure in which a device provides an authenticated IP address in the network system according to the present embodiment. [Figure 7] FIG. 2 is a diagram illustrating a process for notifying an IP address in the network system according to the present embodiment. [Figure 8] FIG. 2 is a diagram illustrating a process for notifying an IP address in the network system according to the present embodiment. [Figure 9] 10 is a sequence chart showing a processing procedure for notifying an IP address in the network system according to the present embodiment. [Figure 10] 1 is a schematic diagram showing an example of a network configuration of a network system according to an embodiment of the present invention; [Figure 11] FIG. 10 is a sequence diagram showing a procedure for data communication between devices having authenticated IP addresses in the network system according to the present embodiment. [Figure 12]It is a sequence diagram showing the procedure of data communication between devices having authenticated IP addresses in the network system according to this embodiment. [Figure 13] It is a flowchart showing the processing procedure for the device according to this embodiment to exchange packets. [Figure 14] It is a flowchart showing the processing procedure for the proxy server according to this embodiment to exchange packets.

Embodiments for Carrying Out the Invention

[0019] Embodiments according to the present disclosure will be described in detail with reference to the drawings. For the same or corresponding parts in the drawings, the same reference numerals are given and the description thereof will not be repeated.

[0020] <A. Overall Configuration of Network System 1> First, the overall configuration of the network system 1 according to this embodiment will be described.

[0021] FIG. 1 is a schematic diagram showing an example of the overall configuration of the network system 1 according to this embodiment. Referring to FIG. 1, it is assumed that a plurality of devices 100-1, 100-2, 100-3, 100-4, 100-5, ··· (hereinafter, may also be collectively referred to as "device 100") are connected to an arbitrary network 2 such as the Internet or an intranet. Some of the devices 100 may be connected to the network 2 via wireless communication established between them and the access point 4. Alternatively, some other devices 100 may be connected to the network 2 via wireless communication established between them and the mobile base station 6.

[0022] Thus, the network 2 may include any one of a local area network (LAN), a wide area network (WAN), a radio access network (RAN), and the Internet.

[0023] Each of the devices 100 connected to the network can be considered a "node" of the network, and in the following description, the devices 100 may also be referred to as a "node."

[0024] In network system 1 according to the present embodiment, data communication is realized between devices 100 in accordance with a procedure to be described later. Note that devices 100 may be physically connected in any manner.

[0025] Device 100 includes any device that has the function of communicating data with other devices using its own IP address. Device 100 may be configured as a standalone communication device, or may be configured as part of or incorporated into some other object.

[0026] More specifically, device 100 may be, for example, a personal computer, a smartphone, a tablet, or a wearable device (for example, a smart watch or AR glasses) attached to a user's body (for example, an arm or a head). Device 100 may also be a control device or a part thereof installed in a smart home appliance, a connected automobile, a factory, or the like.

[0027] The network system 1 according to this embodiment further includes one or more certificate authorities 200. Each of the certificate authorities 200 is a computer configured with one or more servers. Using one or more certificate authorities 200, the IP address of each device 100 is authenticated according to a procedure described below. As a result, each device 100 has an authenticated IP address.

[0028] In this specification, "authenticated IP address" means a state in which the validity of the IP address held by each device 100 is guaranteed to the communication destination or a third party. More specifically, "authenticated IP address" means an IP address that is generated by an irreversible cryptographic hash function and is directly or indirectly authenticated by a certification authority (details will be described later). By using such an "authenticated IP address", it can be guaranteed that the IP address used by each device 100 for data communication is not spoofed.

[0029] As a result, any device 100 included in the network system 1 will be uniquely identified based on the IP address possessed by each device 100. That is, each device can determine the destination of data transmission and the device that is the sender based on the IP address possessed by each device.

[0030] The IP address is assumed to be a global IP address that can also be used for data communication between devices 100 connected to the Internet, but it may also be a private IP address that is used only within a specific network. The IP address has a different number of bits constituting the address depending on the version. In the currently established IPv4 (Internet Protocol Version 4), a 32-bit address range is defined, and in the currently established IPv6 (Internet Protocol Version 6), a 128-bit address range is defined. In this embodiment, the IP address conforming to IPv6 will be mainly described. However, the present disclosure is also applicable to network addresses defined with more bits or network addresses defined with fewer bits.

[0031] <B. Configuration Example of Device 100>

[0032] <B. Configuration Example of Device 100> Next, an example of the hardware and software configuration of device 100 used in network system 1 according to the present embodiment will be described.

[0033] 2 is a schematic diagram showing an example of a hardware configuration of device 100 according to the present embodiment. Referring to Fig. 2, device 100 includes, as a main component, control unit 110 which is a processing circuitry.

[0034] The control unit 110 is a computing entity for providing functions and executing processes according to this embodiment. The control unit 110 may be configured to use a processor and memory as shown in FIG. 2, and have the processor execute computer readable instructions (an OS (Operating System) and a communication processing program as shown in FIG. 3) stored in the memory. Alternatively, the control unit 110 may be configured to use an ASIC (Application Specific Integrated Circuit) in which circuits corresponding to the computer readable instructions are incorporated. The control unit 110 may be realized using a hardwired circuit such as an ASIC (Application Specific Integrated Circuit). Alternatively, the control unit 110 may be realized by implementing a circuit corresponding to computer-readable instructions on an FPGA (Field-Programmable Gate Array). The control unit 110 may also be realized by appropriately combining a processor, memory, ASIC, FPGA, etc.

[0035] In the configuration using a processor and memory as shown in FIG. 2, the control unit 110 includes a processor 102, a main memory 104, a storage 106, and a ROM (Read Only Memory) 108.

[0036] The processor 102 is an arithmetic circuit that sequentially reads and executes computer-readable instructions. The processor 102 is configured, for example, with a central processing unit (CPU), a micro processing unit (MPU), a graphics processing unit (GPU), etc. The control unit 110 may be realized using a plurality of processors 102 (multiprocessor configuration), or may be realized using a processor having a plurality of cores (multicore configuration).

[0037] The main memory 104 is a volatile storage device such as a dynamic random access memory (DRAM) or a static random access memory (SRAM). The processor 102 loads a specified program from among various programs stored in the storage 106 or the ROM 108 onto the main memory 104, and works in cooperation with the main memory 104 to realize various processes according to this embodiment.

[0038] The storage 106 may be, for example, a hard disk drive (HDD), a solid-state drive (SSD), The storage 106 is a non-volatile storage device such as a solid state drive (SSD), flash memory, etc. The storage 106 stores various programs executed by the processor 102 and various data as will be described later.

[0039] The ROM 108 permanently stores various programs executed by the processor 102 and various data to be described later.

[0040] In a configuration in which the processor 102 executes computer-readable instructions stored in memory as shown in FIG. 2, the memory corresponds to the storage 106 and the ROM 108 .

[0041] An example of the programs and data stored in the memory of the device 100 will now be described.

[0042] 3 is a schematic diagram showing an example of the configuration of programs and data of device 100 according to the present embodiment. Referring to Fig. 3, the memory (storage 106 and / or ROM 108) of device 100 stores, for example, an OS 160, a communication processing program 170, and various applications 300 as programs including computer-readable instructions.

[0043] The OS 160 is a program that provides basic functions for realizing the processing executed by the device 100. The communication processing program 170 is a program that mainly provides the functions and executes the processing according to the present embodiment. Note that the communication processing program 170 may also provide the functions and execute the processing according to the present embodiment by using a library provided by the OS 160, etc.

[0044] The various applications 300 are programs for realizing various functions provided by the device 100, and can be installed at the user's discretion. Typically, the various applications 300 provide various processes that utilize the data communication function provided by the communication processing program 170.

[0045] The memory (storage 106 and / or ROM 108) of the device 100 also stores, for example, a private key 172, a public key 174, and a digital certificate 176 as data necessary for providing functions and executing processes according to the present embodiment. The private key 172 and the public key 174 are a key pair generated according to an arbitrary encryption / decryption algorithm. The private key 172 is used for encrypted communication with other devices. The public key 174 is used to determine the IP address of each device 100 according to a procedure described below. The digital certificate 176 is issued by the certificate authority 200 for the public key 174 and is used to ensure the validity of the IP address of the device 100. Typically, the digital certificate 176 includes a hash value (digital signature) calculated from the public key 174 of each device 100 using the private key of the certificate authority 200. Upon receiving the digital certificate 176 , the device 100 uses the public key of the certificate authority 200 to verify the validity of the digital certificate 176 and the public key 174 associated with the digital certificate 176 .

[0046] The procedures for generating a key pair (private key 172 and public key 174), obtaining a digital certificate 176, and using this data will be described later.

[0047] It is not necessary to provide both the storage 106 and the ROM 108, and only one of them may be provided depending on the implementation. Furthermore, when both the storage 106 and the ROM 108 are provided, for example, the key pair (private key 172 and public key 174) may be stored in the ROM 108 to enhance confidentiality.

[0048] 2, the device 100 further includes a network interface 120 for connecting the device 100 to a network. The network interface 120 performs data communication with other devices over the network.

[0049] Network interface 120 includes a wired connection terminal such as an Ethernet (registered trademark) port, a Universal Serial Bus (USB) port, a serial port such as IEEE 1394, or a legacy parallel port. Alternatively, network interface 120 may include a processing circuit and an antenna for wireless communication with a device, a router, a mobile base station, or the like. Wireless communication supported by network interface 120 may be, for example, Wi-Fi (registered trademark), Bluetooth (registered trademark), ZigBee (registered trademark), Low Power Wide Area (LPWA), GSM (registered trademark), W-CDMA, CDMA200, Long Term Evolution (LTE), or a fifth-generation mobile communication system (5G).

[0050] Device 100 may also include optional components: a display 130, an input 140, and a media interface 150.

[0051] Display unit 130 is a component for externally presenting processing results, etc., from processor 102. Display unit 130 may be, for example, an LCD (Liquid Crystal Display) or an organic EL (Electro-Luminescence) display. Display unit 130 may also be a head-mounted display worn on the user's head, or a projector that projects an image onto a screen.

[0052] Input unit 140 is a component for receiving input operations from a user who operates device 100. Input unit 140 may be, for example, a keyboard, a mouse, a touch panel arranged on display unit 130, or operation buttons arranged on the housing of device 100.

[0053] The media interface 150 reads various programs (computer-readable instructions) and / or various data from a non-transitory medium 152 on which the various programs and / or various data are stored.

[0054] The medium 152 may be, for example, an optical medium such as a DVD (Digital Versatile Disc), or a semiconductor medium such as a USB memory. The media interface 150 employs a configuration according to the type of the medium 152. The various programs and / or data read by the media interface 150 may be stored in the storage 106 or the like.

[0055] Instead of installing various programs and / or various data in device 100 via medium 152, necessary programs and data may be installed in device 100 from a distribution server on a network. In this case, the necessary programs and data are obtained via network interface 120.

[0056] As described above, the display unit 130, the input unit 140, and the media interface 150 are optional components, and may be connected from outside the device 100 via any interface such as a USB.

[0057] It is the control unit 110 that provides the functions and executes the processes according to this embodiment, and the technical scope of this application encompasses at least the hardware and / or software for implementing the control unit 110. As described above, the hardware may include not only a configuration consisting of a processor and memory, but also a hardwired circuit using an ASIC or a configuration using an FPGA. In other words, the control unit 110 may be implemented by installing a program on a general-purpose computer, or may be implemented as a dedicated chip.

[0058] In addition, the software executed by the processor may include not only what is distributed via the medium 152 but also what is appropriately downloaded via the distribution server.

[0059] Note that the configuration for providing the functions and executing the processes according to this embodiment is not limited to the control unit 110 shown in FIG. 2, and can be implemented using any technology according to the era in which it is realized.

[0060] <C. Authenticated IP Address> Next, the process for providing an authenticated IP address to each device 100 and the like will be described.

[0061] (c1: IP Address Determination Process) In the network system 1 according to this embodiment, typically, the IP address of each device 100 is authenticated using an authenticated IP address. As an example, the IP address of each device 100 may be authenticated using a public key infrastructure (PKI).

[0062] FIG. 4 is a diagram for explaining the IP address authentication procedure in the network system 1 according to this embodiment. Note that the symbols such as "S1" to "S4" in FIG. 4 correspond to the step numbers shown in FIG. 6.

[0063] Referring to FIG. 4, the device 100 has a key pair consisting of a private key 172 and a public key 174. By inputting the public key 174 into a predetermined hash function 180, a hash value 178 is calculated, and all or part of the calculated hash value 178 is used as the IP address 190 of the device 100.

[0064] In accordance with this process of determining the IP address 190, the device 100 transmits its public key 174 to the certificate authority 200 and associates the public key 174 with a digital certificate 176 issued by the certificate authority 200. The device 100 transmits its own public key 174 and digital certificate 176 to the other device. The other device confirms the legitimacy of the IP address 190 of the device 100 based on the public key 174 and digital certificate 176 published by the device 100. Once the legitimacy of the IP address 190 is confirmed, data communication is initiated using the IP address 190 whose legitimacy has been confirmed. The device 100 and the other device can communicate directly with each other, but in addition to the direct communication process, an inquiry process at the certificate authority 200 may also be included.

[0065] In this way, in the network system 1 according to this embodiment, the IP address 190 itself can be authenticated, and by the device itself holding such an authenticated IP address 190, an autonomous network can be constructed without using an IP address statically or dynamically assigned to each device.

[0066] The process for providing an authenticated IP address in network system 1 according to the present embodiment will now be described in detail.

[0067] The key pair, private key 172 and public key 174, may be generated by device 100 itself, or may be provided from an external source and pre-stored in device 100. If provided from an external source, device 100 may acquire only private key 172 and generate public key 174 by itself.

[0068] As an example of a method for generating public key 174, which is a key pair, a bit string of a predetermined length (e.g., 512 bits) generated by a random number generator may be used as private key 172, and public key 174 consisting of a bit string of a predetermined length (e.g., 256 bits) may be generated from private key 172 according to a known encryption algorithm (e.g., elliptic curve encryption algorithm). Note that when device 100 itself generates the key pair, the random number generator may be realized using a function provided by OS 160, or may be realized using a hardwired circuit such as an ASIC.

[0069] A known irreversible cryptographic hash function (for example, BLAKE) can be used as the hash function 180. The hash function 180 calculates a hash value 178 consisting of a bit string of a predetermined length (for example, 256 bits).

[0070] In addition to public key 174, an arbitrary keyword may be input to hash function 180. A message associated with a predetermined organization may be used as the arbitrary keyword. A message including the name of a trademark owned by the predetermined organization may be used as the message associated with the predetermined organization. For example, the name of a registered trademark owned by the predetermined organization (e.g., "connectFree") may be used as the keyword to be input to hash function 180. By adopting such an implementation method, it is possible to prevent a third party other than the predetermined organization from implementing network system 1 according to this embodiment and related methods and programs without the permission of the predetermined organization.

[0071] All or part of hash value 178 calculated by hash function 180 is used as IP address 190. For example, when a 256-bit (64 hexadecimal digits) hash value 178 is calculated, any 32 digits (e.g., the first 32 digits) of the 64-digit hash value 178 may be determined as IP address 190 (128 bits) corresponding to IPv6. Alternatively, the first 8 digits of the 64-digit hash value 178 may be determined as IP address 190 (32 bits) corresponding to IPv4.

[0072] Alternatively, the 128-bit hash value 178 may be calculated from the hash function 180, taking into account the IP address 190 (128 bits) corresponding to IPv6. In this case, the entire calculated hash value 178 can be determined as the IP address 190 (128 bits) corresponding to IPv6.

[0073] According to this embodiment, the IP address 190 unique to the device 100 can be determined based on the public key 174 of the device 100. In this way, the device 100 can be connected to a network such as the Internet using the IP address 190 determined by the device 100. Furthermore, the device 100 can perform data communication using the IP address 190 determined by itself, even if there is no service provider (server) that manages global IP addresses, such as an Internet service provider (ISP). Furthermore, the device 100 can connect to a global network such as the Internet and perform data communication using the IP address 190 determined by itself, even if there is no server that manages private IP addresses, such as a DHCP (Dynamic Host Configuration Protocol) server implemented in an access point or the like. Therefore, the user experience and convenience of connecting to a network such as the Internet can be improved. This can improve convenience for users.

[0074] (c2: Unique string) The IP address 190 determined by the device 100 may be identified as having been determined in accordance with the processing procedure according to this embodiment. To achieve this identification, for example, a predetermined unique value (unique character string) for identification may be included in the IP address 190. In other words, the determined IP address may include the predetermined unique value (unique character string) for identification.

[0075] As an example, the first two digits (the first and second digits from the top) of the IP address 190 expressed in hexadecimal may be fixed to a predetermined unique string (e.g., "FC"). Since the hash function 180 is typically a one-way function, it is not possible to reverse-calculate the public key 174 from the IP address 190. Therefore, a random number generator may be used to repeatedly generate the private key 172 and the public key 174 until the determined IP address 190 satisfies a predetermined condition (in this case, the first two digits are a predetermined unique value). In other words, the public key 174 may be determined so that the IP address 190 determined based on a hash value calculated from the public key 174 according to the hash function conforms to a predetermined format.

[0076] In this way, by including a predetermined unique value for identification (for example, the first two digits are "FC") in IP address 190, a third party can determine whether IP address 190 of device 100 was determined by device 100 itself.

[0077] (c3: Type-specific information) The IP address 190 determined by the device 100 may include information that can identify the type of the device 100. To achieve this identification, for example, the IP address 190 may include a value that corresponds to the type of the device 100. In other words, the determined IP address 190 may include a value that corresponds to the type of the device 100 that determined the IP address 190.

[0078] As an example, a value (type-specific information) according to the type of device 100 may be embedded in the third and fourth digits from the beginning of the IP address 190 expressed in hexadecimal numbers.

[0079] Fig. 5 is a diagram showing an example of type specifying information embedded in an IP address used in network system 1 according to the present embodiment. The type specifying information shown in Fig. 5 may be stored in advance in ROM 108 (see Fig. 2) of control unit 110 of each device 100. As an example, a value according to the type of device as shown in Fig. 5 can be used.

[0080] As shown in FIG. 5, for example, if the type of device 100 is a personal computer, the value "00" indicating a personal computer is set in the third and fourth digits from the beginning of the IP address 190.

[0081] As described above, hash function 180 is usually a one-way function, and therefore public key 174 cannot be calculated backward from IP address 190. Therefore, private key 172 and public key 174 may be repeatedly generated using a random number generator until the determined IP address 190 satisfies a predetermined condition (in this case, the third and fourth digits from the beginning are values ​​indicating the type of device 100). In other words, public key 174 may be determined so that IP address 190 determined based on a hash value calculated from public key 174 according to the hash function matches a predetermined format.

[0082] In this way, by including a value indicating the type of device 100 in the IP address 190, The three parties can identify the type of device 100 from the IP address 190 determined by the device 100.

[0083] (c4: Registering a public key 174 and obtaining a digital certificate 176) Next, the registration of the public key 174 and the acquisition of the digital certificate 176 will be described.

[0084] The device 100 obtains the digital certificate 176 for verifying the validity of the public key 174 from the certification authority 200. The procedure for obtaining the digital certificate 176 is to send the public key 174 from the device 100 to the certification authority 200 to register it, and to obtain the digital certificate 176 associated with the registered public key 174 from the certification authority 200.

[0085] More specifically, device 100 (control unit 110) transmits public key 174 and a request for issuing a digital certificate (hereinafter also referred to as a "certificate signing request") to certificate authority 200 via the network. In response to the certificate signing request received from device 100, certificate authority 200 registers public key 174 and issues digital certificate 176 associated with registered public key 174. Then, certificate authority 200 transmits digital certificate 176 to device 100 via the network.

[0086] Typically, the digital certificate 176 includes information about the owner of the digital certificate 176 (in this example, the device 100), information about the issuer of the digital certificate 176 (in this example, the certificate authority 200), the issuer's digital signature, and the expiration date of the digital certificate 176.

[0087] Certificate authority 200 may be operated by a specific organization, or may be an intermediate certificate authority associated with a root certificate authority operated by a specific organization. Registration of public key 174 and issuance of digital certificate 176 associated with public key 174 may require a specific fee and / or maintenance fee from the specific organization.

[0088] According to the present embodiment, public key 174 is directly authenticated by certificate authority 200 through registration and acquisition of public key 174, and thus IP address 190 determined based on public key 174 is also indirectly authenticated by certificate authority 200. Such authentication by certificate authority 200 enables device 100 to realize data communication over the network using authenticated IP address 190.

[0089] Note that the digital certificate 176 associated with the public key may include information related to the attributes of the device 100 (hereinafter also referred to as "attribute information") in order to improve confidentiality. The attribute information of the device 100 may include, for example, version information of the OS 160 and communication processing program 170 of the device 100, or the serial number of the hardware (e.g., processor, storage, etc.) that constitutes the device 100. In this case, the device 100 may transmit the attribute information of the device 100 to the certificate authority 200 when transmitting the public key 174 and the certificate signing request. Note that the attribute information of the device 100 included in the digital certificate 176 may be encrypted using a known irreversible cryptographic hash function or the like.

[0090] In this way, by including the attribute information of device 100 in digital certificate 176, it is possible to authenticate that digital certificate 176 has been issued in response to a certificate signing request from device 100 itself. In other words, it is possible to more reliably prevent a device other than device 100 from masquerading as device 100 and using public key 174 and digital certificate 176 of device 100.

[0091] (c5: Processing procedure) Next, the procedure for providing an authenticated IP address in each device 100 will be described. and explain.

[0092] 6 is a flowchart showing a processing procedure in which device 100 provides an authenticated IP address in network system 1 according to the present embodiment. The processing procedure shown in FIG. 6 is executed in each device 100, and each step shown in FIG. 6 is executed by control unit 110 of each device 100.

[0093] 6, device 100 acquires a key pair (private key 172 and public key 174) generated according to an arbitrary algorithm (step S1). This key pair may be generated by device 100 itself, or may be acquired by device 100 from an external source. Alternatively, device 100 may acquire only private key 172 from an external source and generate public key 174 internally.

[0094] Next, the device 100 calculates a hash value 178 by inputting the public key 174 into a predetermined hash function 180, and determines an IP address 190 of the device 100 from all or part of the calculated hash value 178 (step S2). That is, the device 100 determines its own IP address based on the hash value 178 calculated from the public key 174 according to the hash function 180.

[0095] In addition, an appropriate key pair (private key 172 and public key 174) may be generated so that IP address 190 includes a unique string (e.g., the first and second digits of IP address 190) and / or type-specific information (e.g., the first and fourth digits of IP address 190).

[0096] Furthermore, the device 100 transmits the public key 174 and a request for issuing a digital certificate (certificate signing request) to the certificate authority 200 (step S3). In response to the certificate signing request received from the device 100, the certificate authority 200 registers the public key 174 and issues a digital certificate 176 associated with the registered public key 174. The certificate authority 200 then transmits the digital certificate 176 to the device 100 via the network. The device 100 then receives and stores the digital certificate 176 from the certificate authority 200 (step S4).

[0097] Thus, the device 100 obtains a digital certificate 176 associated with the public key 174 from a certificate authority.

[0098] The order in which the process of step S2 and the processes of steps S3 and S4 are performed does not matter.

[0099] <Notification of D.IP Address> Next, the process related to the notification of IP addresses between devices 100 in the network system 1 according to the present embodiment will be described.

[0100] FIG. 7 and FIG. 8 are diagrams for explaining the process related to the notification of IP addresses in the network system 1 according to the present embodiment. FIGS. 7 and 8 show an example of exchanging IP addresses among three devices 100-1, 100-2, and 100-3. Note that the same process is possible between two devices 100, and the same process is also possible among more devices 100.

[0101] In the state shown in FIGS. 7 and 8, each of the devices 100-1, 100-2, and 100-3 has determined IP addresses 190-1, 190-2, and 190-3 respectively according to the procedure as described above, and It is also assumed that the registration of public keys 174-1, 174-2, and 174-3 with the certification authority 200 and the acquisition of electronic certificates 176-1, 176-2, and 176-3 from the certification authority 200 have been completed respectively.

[0102] As shown in FIGS. 7 and 8, each device 100 transmits (broadcasts) the public key 174 and the electronic certificate 176 associated with the public key 174 that each device has at regular intervals or for each event. That is, each device 100 transmits the public key 174 and the electronic certificate 176 to other devices.

[0103] 7 shows an example in which device 100-1 transmits (broadcasts) public key 174-1 and digital certificate 176-1 associated with public key 174-1. In the example shown in Fig. 7, it is assumed that devices 100-2 and 100-3 receive public key 174-1 and digital certificate 176-1 transmitted by device 100-1. Devices 100-2 and 100-3 then determine whether digital certificate 176-1 is valid, and if it is determined to be valid, determine IP address 190-1 of device 100-1 based on the associated public key 174-1 and register it in connection tables 194-2 and 194-3, respectively.

[0104] Here, the connection table contains information about each device 100 for data communication, and each device 100 refers to the connection table to identify the IP address of the destination device 100, and establish the necessary session.

[0105] More specifically, device 100-2 first determines whether digital certificate 176-1 broadcast from device 100-1 is valid. In this process of determining validity, the integrity of digital certificate 176-1 is verified.

[0106] As an example of the integrity verification process, the device 100-2 first checks the owner information of the digital certificate 176-1, the issuer information of the digital certificate 176-1, and the existence of the issuer's digital signature. The device 100-2 then determines whether the digital certificate 176-1 is within its expiration date. Furthermore, the device 100-2 determines whether the issuer of the digital certificate 176-1 is trustworthy. In particular, if the digital certificate 176-1 was issued by an intermediate certification authority, the device 100-2 identifies a root certification authority associated with the intermediate certification authority that issued the digital certificate 176-1 and determines whether the identified root certification authority is trustworthy. For example, if the identified root certification authority matches one or more root certification authorities stored in the device 100-1, the device 100-2 determines that the issuer of the digital certificate 176-1 is trustworthy.

[0107] If the above-described determination process is passed, device 100-2 determines that digital certificate 176-1 broadcast from device 100-1 is valid. Device 100-2 then calculates hash value 178-1 by inputting public key 174-1 broadcast from device 100-1 into a predetermined hash function 180, and determines IP address 190-1 of device 100-1 using all or part of the calculated hash value 178-1. Here, it is assumed that devices 100-1 and 100-2 share a common hash function 180. It is also assumed that the process of determining IP address 190-1 from hash value 178-1 is common between devices 100-1 and 100-2.

[0108] Through the above processing, the device 100-2 can determine the IP address 190-1 of the device 100-1, and then adds an entry for the determined IP address 190-1 of the device 100-1 to the connection table 194-2. The public key 174-1 may be registered in association with the IP address 190-1.

[0109] The same process as that of the device 100-2 is also performed in the device 100-3, and an entry for the determined IP address 190-1 of the device 100-1 is added to the connection table 194-3 of the device 100-3. The public key 174-1 may be registered in association with the IP address 190-1.

[0110] By the process shown in FIG. 7, the device 100-2 and the device 100-3 can obtain the IP address 190-1 of the device 100-1.

[0111] 8 shows an example in which device 100-2 transmits (broadcasts) public key 174-2 and digital certificate 176-2 associated with public key 174-2. In the example shown in Fig. 8, it is assumed that devices 100-1 and 100-3 receive public key 174-2 and digital certificate 176-2 transmitted by device 100-2. Then, devices 100-1 and 100-3 determine whether digital certificate 176-2 is valid, and if it is determined to be valid, determine IP address 190-2 of device 100-2 based on the associated public key 174-2 and register it in connection tables 194-1 and 194-3, respectively.

[0112] The series of processes executed in devices 100-1 and 100-3 are similar to the processes described with reference to Fig. 7, and therefore detailed description will not be repeated. By the process shown in Fig. 8, devices 100-1 and 100-3 can obtain IP address 190-2 of device 100-2.

[0113] Furthermore, device 100-3 may transmit (broadcast) public key 174-3 and digital certificate 176-3 associated with public key 174-3. Assume that devices 100-1 and 100-2 successfully receive public key 174-3 and digital certificate 176-3 transmitted by device 100-3. Then, devices 100-1 and 100-2 determine whether digital certificate 176-3 is valid. If it is determined to be valid, devices 100-1 and 100-2 determine IP address 190-3 of device 100-3 based on the associated public key 174-3 and register it in connection tables 194-1 and 194-2, respectively. Through this process, devices 100-1 and 100-2 can obtain IP address 190-3 of device 100-3.

[0114] Fig. 9 is a sequence chart showing a processing procedure relating to notification of an IP address in network system 1 according to the present embodiment. Fig. 9 shows processing procedures in three devices 100-1, 100-2, and 100-3, corresponding to Figs.

[0115] The device 100-1 transmits (broadcasts) the public key 174-1 and the digital certificate 176-1 associated with the public key 174-1 (sequence SQ10).

[0116] Upon receiving the public key 174-1 and digital certificate 176-1 transmitted by the device 100-1, the device 100-2 determines the validity of the digital certificate 176-1 (sequence SQ11). If the digital certificate 176-1 is determined to be valid, the device 100-2 determines the IP address 190-1 of the device 100-1 based on the public key 174-1 (sequence SQ12), and registers the determined IP address 190-1 of the device 100-1 in the connection table 194-2 (sequence SQ13).

[0117] Similarly, upon receiving the public key 174-1 and the digital certificate 176-1 transmitted by the device 100-1, the device 100-3 determines the validity of the digital certificate 176-1. (Sequence SQ14). If it is determined that the digital certificate 176-1 is valid, the device 100-3 determines the IP address 190-1 of the device 100-1 based on the public key 174-1 (sequence SQ15), and registers the determined IP address 190-1 of the device 100-1 in the connection table 194-3 (sequence SQ16).

[0118] Additionally, the device 100-2 transmits (broadcasts) the public key 174-2 and the digital certificate 176-2 associated with the public key 174-2 (sequence SQ20).

[0119] Upon receiving the public key 174-2 and digital certificate 176-2 transmitted by the device 100-2, the device 100-1 determines the validity of the digital certificate 176-2 (sequence SQ21). If the digital certificate 176-2 is determined to be valid, the device 100-1 determines the IP address 190-2 of the device 100-2 based on the public key 174-2 (sequence SQ22), and registers the determined IP address 190-2 of the device 100-2 in the connection table 194-1 (sequence SQ23).

[0120] Similarly, upon receiving the public key 174-2 and digital certificate 176-2 transmitted by the device 100-2, the device 100-3 determines the validity of the digital certificate 176-2 (sequence SQ24). If the digital certificate 176-2 is determined to be valid, the device 100-3 determines the IP address 190-2 of the device 100-2 based on the public key 174-2 (sequence SQ25), and registers the determined IP address 190-2 of the device 100-2 in the connection table 194-3 (sequence SQ26).

[0121] Furthermore, the device 100-3 transmits (broadcasts) the public key 174-3 and the digital certificate 176-3 associated with the public key 174-3 (sequence SQ30).

[0122] Upon receiving the public key 174-3 and digital certificate 176-3 transmitted by the device 100-3, the device 100-1 determines the validity of the digital certificate 176-3 (sequence SQ31). If the digital certificate 176-3 is determined to be valid, the device 100-1 determines the IP address 190-3 of the device 100-3 based on the public key 174-3 (sequence SQ32), and registers the determined IP address 190-3 of the device 100-3 in the connection table 194-1 (sequence SQ33).

[0123] Similarly, upon receiving the public key 174-3 and digital certificate 176-3 transmitted by the device 100-3, the device 100-2 determines the validity of the digital certificate 176-3 (sequence SQ34). If the digital certificate 176-3 is determined to be valid, the device 100-2 determines the IP address 190-3 of the device 100-3 based on the public key 174-3 (sequence SQ35), and registers the determined IP address 190-3 of the device 100-3 in the connection table 194-2 (sequence SQ36).

[0124] The processing of sequences SQ10 to SQ16, the processing of sequences SQ20 to SQ26, and the processing of sequences SQ30 to SQ36 can be executed in any order or in parallel.

[0125] In this way, when each device 100 receives public key 174 and digital certificate 176 associated with public key 174 from another device, it determines the validity of digital certificate 176 (sequences SQ11, SQ14, SQ21, SQ24, SQ31, SQ34). Then, when each device 100 determines that digital certificate 176 is valid, it determines the IP address of the other device based on a hash value calculated from public key 174 according to a hash function (sequences SQ12, SQ15, SQ22, SQ25, SQ32, SQ35).

[0126] As described above, in the network system 1 according to the present embodiment, the IP address 190 of the other device 100 is determined based on the public key 174 associated with the electronic certificate 176 on the condition that the electronic certificate 176 transmitted from the other device 100 is determined to be valid. Since the IP address 190 is determined based on the public key 174 on the condition that the electronic certificate 176 associated with the public key 174 is determined to be valid, the validity of the public key 174 and the validity of the IP address 190 can be guaranteed. Therefore, reliable data communication can be realized between the devices 100.

[0127] Also, in the network system 1 according to the present embodiment, since the IP address of each device 100 can be known based on the public key 174 broadcast by each device 100, the devices 100 can be directly connected to each other even if there is no server for managing the IP address. In particular, even if there is no virtual private network (VPN) server or the like, communication with ensured confidentiality can be realized between the devices 100, so that the cost and power consumption for maintaining the VPN server can be reduced.

[0128] <E. Data Communication Processing> Next, the data communication processing in the network system 1 according to the present embodiment will be described.

[0129] (e1: Background) In the network system 1 according to the present embodiment, data is exchanged between the devices 100 by so-called P2P (Peer to Peer). Also, each device 100 has a routing function and a data transfer function, and P2P data transfer is repeated until the destination device is reached. Such a function can realize a network capable of autonomously performing data communication.

[0130] Data (typically, packets or frames) communicated via P2P is encrypted using an encryption key established between the devices 100 involved in each P2P, thereby achieving secure data communication. In the following description, it is assumed that data is transmitted in the form of "packets" as a typical example.

[0131] Fig. 10 is a schematic diagram showing an example of a network configuration of a network system 1 according to the present embodiment. Network system 1 shown in Fig. 10 includes a local line 10 including an access point 4, the Internet 20, and a restricted network 30. A proxy server 22 that also functions as a gateway is disposed between local line 10 and the Internet 20. A relay server 32 that also functions as a gateway is disposed between local line 10 and restricted network 30.

[0132] The Internet 20 includes one or more servers 24 that provide various network services. The restricted network 30 is a network that is completely or partially isolated from the Internet 20 and can be accessed only by devices 100 (or users) belonging to a specific company or organization. The restricted network 30 includes one or more servers 34 that provide various network services. Here, the various network services include, for example, web, email, database, etc. The proxy server 22 and relay server 32 can also be considered as servers that provide network services.

[0133] As an example, in the network system 1 shown in FIG. 10, the device 100, the proxy server 22, the relay server 32, and the server 34 all have authenticated IP addresses. In other words, these devices are capable of data communication using the authenticated IP addresses described above. In contrast, one or more servers 24 on the Internet 20 are devices that only have normal IP addresses (i.e., the assigned IP addresses are not authenticated).

[0134] Considering an existing network, there may be data exchanged with devices that do not support data communication using authenticated IP addresses, as shown in Fig. 10. Therefore, by implementing the following functions, device 100 according to this embodiment can exchange data not only with devices that support data communication using authenticated IP addresses, but also with devices that do not have authenticated IP addresses or that do not support data communication using authenticated IP addresses.

[0135] (e2: Data communication between devices with authenticated IP addresses) First, data communication between devices having authenticated IP addresses will be described. As an example, data communication between the device 100 and the server 34 in the network system 1 shown in FIG.

[0136] Fig. 11 is a sequence diagram showing the procedure for data communication between devices having authenticated IP addresses in network system 1 according to this embodiment. Fig. 11 shows a data transmission method in a network to which a plurality of devices are connected. Fig. 11 shows a case in which an arbitrary request is transmitted from device 100 to server 34, and server 34 responds to device 100 with the results of performing processing in accordance with the request. Note that Fig. 10 lists the same sequence numbers as those corresponding to the main processing shown in Fig. 11.

[0137] 11, the device 100 generates an encrypted packet including a request to the server 34 (sequence SQ100). A session has been established in advance between the device 100 and the server 34, and a packet from the device 100 to the server 34 is encrypted according to the encryption method agreed upon in the established session. The generated encrypted packet is addressed to the server 34.

[0138] Next, the device 100 establishes a session with the relay server 32 and transmits the encrypted packet via P2P (sequence SQ102). That is, a process is executed in which the generated encrypted packet is transferred from the device 100 to the server 34 via P2P. The encrypted packet may be further encrypted during P2P transmission. In this case, the encryption method agreed upon in the session established between the device 100 and the relay server 32 is followed.

[0139] The relay server 32 further transfers the encrypted packet received from the device 100 to the server 34. That is, the relay server 32 establishes a session with the server 34 and transmits the encrypted packet via P2P (sequence SQ104). Note that the encrypted packet may be further encrypted when transmitted via P2P.

[0140] The server 34 determines that the encrypted packet received from the relay server 32 is addressed to its own device, and decrypts the encrypted packet (sequence SQ106). The server 34 then executes processing in accordance with the request included in the decryption result of the encrypted packet (sequence SQ108). The server 34 generates an encrypted packet including the execution result of the processing (sequence SQ110). The server 34 transmits the encrypted packet to the relay server 32 via P2P (sequence SQ112). The relay server 32 further forwards the encrypted packet received from the server 34 to the device 100. That is, the relay server 32 transmits the encrypted packet via P2P. The request is sent to the device 100 (sequence SQ114).

[0141] The device 100 determines that the encrypted packet received from the relay server 32 is addressed to the device itself and decrypts the encrypted packet (sequence SQ116).The device 100 then executes processing such as displaying the result using the processing execution result included in the decryption result of the encrypted packet (sequence SQ118).

[0142] As described above, data is securely exchanged between devices with authenticated IP addresses by sequentially transferring encrypted packets via P2P.

[0143] (e3: Data communication with devices that do not support authenticated IP addresses) Next, data communication with a device that does not support an authenticated IP address will be described. As an example, data communication between the device 100 and the server 24 in the network system 1 shown in FIG.

[0144] Fig. 12 is a sequence diagram showing the procedure for data communication between devices having authenticated IP addresses in network system 1 according to this embodiment. Fig. 12 shows a case in which device 100 transmits an arbitrary request to server 24, and server 24 performs processing in accordance with the request and returns the result to device 100. In this case, proxy server 22 serves as a proxy server between device 100 and server 24. Note that Fig. 10 lists the same sequence numbers as those corresponding to the main processes shown in Fig. 12.

[0145] In the following explanation, as a typical example, only the proxy operation of the proxy server 22 will be described, but it is not necessary to implement exactly the same processing as the proxy operation, and processing similar to the processing related to the proxy operation may be adopted. Also, in addition to the proxy operation, for example, a virus check function, a filtering function, etc. may be included.

[0146] 12, when the device 100 receives a packet that satisfies a predetermined condition from an application or the like, the device 100 transmits a proxy operation request to the proxy server 22 (sequence SQ200). The predetermined condition includes, for example, receiving a packet addressed to a device that does not support data communication using an authenticated IP address. In response to the proxy operation request, the proxy server 22 enables the proxy operation for the device 100. In this manner, a process is executed in which the device 100 transmits a request to the proxy server 22 to enable the proxy operation.

[0147] The proxy operation request may also be transmitted from the device 100 to the proxy server 22 via P2P. Furthermore, the proxy operation request transmitted via P2P may be encrypted.

[0148] The proxy operation requests from the proxy server 22 and the device 100 may be implemented using a known protocol. More specifically, a protocol such as SOCKS (SOCKS4, SOCKS4a, SOCKS5) may be used.

[0149] Next, the device 100 generates an encrypted packet including a request to the server 34 (sequence SQ202). A session has been established in advance between the device 100 and the proxy server 22, and packets from the device 100 to the proxy server 22 are encrypted according to the encryption method agreed upon in the established session. The generated encrypted packets are addressed to the proxy server 22, but also include packets addressed to the server 34.

[0150] Next, the device 100 transmits the encrypted packet to the proxy server 22 via P2P (sequence SQ204). That is, a process is executed in which the generated encrypted packet is transferred from the device 100 to the proxy server 22 via P2P. The encrypted packet may be further encrypted during P2P transmission. In this case, the encryption method agreed upon in the session established between the device 100 and the proxy server 22 is followed.

[0151] The proxy server 22 first decrypts the encrypted packet received from the device 100 (sequence SQ206). This is because a normal communication protocol using IP addresses is used on the path beyond the proxy server 22. Then, the server 34 performs data communication with the server 24 on behalf of the device 100 in accordance with the request included in the decrypted result of the encrypted packet. That is, the proxy server 22 generates a normal packet including the request included in the decrypted result of the encrypted packet (sequence SQ208). Then, the proxy server 22 transmits the generated normal packet to the server 24 (sequence SQ210). In this way, the proxy server 22 executes a process of decrypting the encrypted packet and transmitting the generated normal packet to the server 24.

[0152] When generating a normal packet, the proxy server 22 may appropriately change the header information included in the packet from the device 100.

[0153] Then, the proxy server 22 transmits the generated normal packet to the server 24 (sequence SQ210). The transmission of this normal packet does not necessarily have to be P2P, and the packet may be transferred appropriately according to normal TCP / IP, UDP / IP, or the like.

[0154] Upon receiving the normal packet from the proxy server 22, the server 24 executes processing according to the request contained in the normal packet (sequence SQ212), and then transmits a normal packet (response packet) including the execution result of the processing to the proxy server 22 (sequence SQ214).

[0155] Proxy server 22 receives the response packet from server 24 and generates an encrypted packet including the received normal packet (sequence SQ216). This generated encrypted packet is addressed to device 100. Proxy server 22 then transmits the generated encrypted packet to device 100 via P2P (sequence SQ218). In this manner, the process of transferring the encrypted packet from proxy server 22 to device 100 via P2P is executed.

[0156] The device 100 determines that the encrypted packet received from the proxy server 22 is addressed to the device itself and decrypts the encrypted packet (sequence SQ220).The device 100 then executes processing such as displaying the result using the processing execution result included in the decryption result of the encrypted packet (sequence SQ222).

[0157] As described above, data is securely exchanged between devices having authenticated IP addresses by sequentially transferring encrypted packets via P2P. On the other hand, when exchanging data with a device that does not support authenticated IP addresses, proxy server 22 responds on behalf of the device, allowing data to be exchanged with any device.

[0158] (e4: Processing procedure) Next, the processing procedure in the device 100 and the processing procedure in the proxy server 22 will be described.

[0159] Fig. 13 is a flowchart showing a processing procedure for device 100 according to the present embodiment to exchange packets. Fig. 13 shows an example of a communication processing method in device 100 connected to a network. Each step shown in Fig. 13 is executed by control unit 110 (see Fig. 2) of device 100 (typically, realized by cooperation between a processor and a memory).

[0160] 13, it is determined whether or not a request to transmit a packet destined for another device has been issued from any application 300 or the like executed on device 100 (step S100). If a request to transmit a packet destined for another device has not been issued (NO in step S100), the process proceeds to step S150 and subsequent steps.

[0161] In response to this, when a request to send a packet addressed to another device is received (YES in step S100), the device 100 determines whether the destination device is a device that supports data communication using an authenticated IP address (step S102). Determining whether the destination device is a device that supports data communication using an authenticated IP address means determining whether the destination device is capable of exchanging encrypted packets.

[0162] In step S102, the determination may be made based on, for example, whether the IP address of the destination device has a value such as that shown in Fig. 5. Alternatively, the device 100 may determine that data communication using an authenticated IP address is supported only if the IP address matches a list registered in advance in the device 100, and otherwise determine that the IP address is not supported.

[0163] If the destination device is a device that supports data communication using an authenticated IP address (YES in step S102), the device 100 generates an encrypted packet addressed to the specified other device in accordance with the encryption method agreed upon in the session with the destination device (step S104). That is, if the destination device is capable of exchanging encrypted packets, the device 100 generates an encrypted packet addressed to the destination device in accordance with the packet transmission request. Next, the device 100 transmits the generated encrypted packet to an adjacent device via P2P (step S106). Finally, the encrypted packet is transferred to the destination device via P2P. Then, the processing from step S150 onwards is executed.

[0164] On the other hand, if the destination device is not a device that supports data communication using an authenticated IP address (NO in step S102), the device 100 identifies the proxy server 22 that will be the proxy server for the device 100 (step S108). This identification of the proxy server 22 is typically performed using an IP address.

[0165] Then, the device 100 determines whether a proxy operation request has been sent to the identified proxy server 22 (step S110). If a proxy operation request has not been sent to the identified proxy server 22 (NO in step S110), the device 100 sends a proxy operation request to the identified proxy server 22 (step S112). The proxy operation request corresponds to a request to enable the proxy operation. If a proxy operation request has been sent to the identified proxy server 22 (YES in step S110), the process of step S112 is skipped.

[0166] Next, the device 100 generates a normal packet addressed to the specified other device (step S114), and further, in the session with the identified proxy server 22, In accordance with the agreed-upon encryption method, the device 100 generates an encrypted packet including the generated normal packet and addressed to the identified proxy server 22 (step S116). That is, if the destination device is not capable of exchanging encrypted packets, the device 100 generates an encrypted packet including a packet addressed to the destination device in accordance with the packet transmission request. Next, the device 100 transmits the generated encrypted packet to an adjacent device via P2P (step S106). Finally, the encrypted packet is transferred via P2P to the proxy server 22 that serves as the proxy server for the device 100. Then, the processing from step S150 onwards is executed.

[0167] The processes in steps S100 to S116 correspond to the processes related to packet transmission, and the processes in step S150 and after correspond to the processes related to packet reception.

[0168] In step S150, the device 100 determines whether or not an encrypted packet has been received from another device (step S150). If an encrypted packet has not been received from another device (NO in step S150), the process from step S100 onwards is repeated.

[0169] If an encrypted packet has been received from another device (YES in step S150), the device 100 determines whether the received encrypted packet is addressed to the device itself (step S152). If the received encrypted packet is addressed to the device itself (YES in step S152), the device 100 decrypts the received encrypted packet (step S154) and executes necessary processing based on the decryption result of the encrypted packet (step S156). Then, the processing from step S100 onwards is repeated.

[0170] On the other hand, if the received encrypted packet is not addressed to the device itself (NO in step S152), the device 100 transfers the received encrypted packet to another device via P2P (step S158), and then repeats the processing from step S100 onwards.

[0171] 14 is a flowchart showing a processing procedure for exchanging packets by proxy server 22 according to the present embodiment. Each step shown in FIG. 14 is executed by a control unit of proxy server 22 (typically, realized by cooperation between a processor and a memory).

[0172] 14, the proxy server 22 determines whether or not a proxy operation request has been received from any device (step S200). If a proxy operation request has been received from any device (YES in step S200), the proxy server 22 establishes a session related to the proxy operation for the requesting device (step S202). If a proxy operation request has not been received from any device (NO in step S200), the processing of step S202 is skipped.

[0173] Next, proxy server 22 determines whether it has received an encrypted packet addressed to its own device from any device (step S204). If it has received an encrypted packet addressed to its own device from any device (YES in step S204), proxy server 22 decrypts the received encrypted packet (step S206) and executes processing in accordance with the request included in the decrypted result of the encrypted packet (step S208). If it has not received an encrypted packet addressed to its own device from any device (NO in step S204), the processes of steps S206 and S208 are skipped.

[0174] Next, the proxy server 22 determines whether or not it has received a normal packet addressed to its own device from any device (step S210). Packets including responses from 24 etc. are assumed. If the proxy server 22 has received a normal packet addressed to itself from any device (YES in step S210), it generates an encrypted packet including the received normal packet (step S212). Then, the proxy server 22 transmits the generated encrypted packet to the device 100 via P2P (step S214). If the proxy server 22 has not received a normal packet addressed to itself from any device (NO in step S210), the processes in steps S212 and S214 are skipped. Then, the processes below step S200 are repeated.

[0175] As described above, there may be a network in which devices having authenticated IP addresses and capable of exchanging encrypted packets coexist with devices not having authenticated IP addresses and not capable of exchanging encrypted packets. The network system 1 according to the present embodiment can realize necessary data communication in such a network by using a device serving as a proxy server, in the same procedure as exchanging encrypted packets with a device having an authenticated IP address, from the viewpoint of the source device.

[0176] <F. Advantages> According to the network system 1 according to the present embodiment, even in a network including a device that cannot exchange encrypted packets as the destination device, it is possible to realize P2P-based data communication that can maintain both the processing affinity and the security level.

[0177] It should be considered that the embodiments disclosed this time are illustrative in all respects and not restrictive. The scope of the present invention is shown not by the above description but by the claims, and it is intended that all modifications within the meaning and scope equivalent to the claims are included.

Explanation of Reference Numerals

[0178] 1 network system, 2 network, 4 access point, 6 mobile base station, 10 local line, 20 Internet, 22 proxy server, 24, 34 server, 30 restricted network, 32 relay server, 100 device, 102 processor, 104 main memory, 106 storage, 108 ROM, 110 control unit, 120 network interface, 130 display unit, 140 input unit, 150 media interface, 152 media, 160 OS, 170 communication processing program, 172 private key, 174 public key, 176 digital certificate, 178 hash value, 180 hash function, 190 IP address, 194 connection table, 200 certification authority, 300 application.

Claims

1. A data transmission method in a network to which a plurality of devices are connected, comprising: generating, at a first device, a first encrypted packet destined for a second device; transferring the first encrypted packet from the first device to the second device in a peer-to-peer (P2P) manner; generating, at the first device, a second encrypted packet addressed to a third device that serves as a proxy server for the first device, the second encrypted packet including a packet addressed to a fourth device; forwarding the second encrypted packet from the first device to the third device via P2P; and transmitting, in the third device, a normal packet generated by decrypting the second encrypted packet to the fourth device.

2. and generating, at the third device, a third encrypted packet addressed to the first device upon receiving a response packet from the fourth device, the third encrypted packet including the response packet; The data transmission method of claim 1 , further comprising the step of transferring the third encrypted packet from the third device to the first device via P2P.

3. The data transmission method according to claim 1 or 2, further comprising the step of transmitting a request to enable proxy operation from the first device to the third device.

4. a step of transmitting, in each of the first device, the second device, and the third device, a public key and a digital certificate associated with the public key that each device has to another device; The data transmission method according to any one of claims 1 to 3, further comprising a step of determining, in a device that receives the public key and the electronic certificate, an IP address of the device that sent the public key and the electronic certificate, based on a hash value calculated from the public key according to a hash function.

5. A communication processing method for a device connected to a network, comprising: determining whether the destination device is capable of receiving and transmitting encrypted packets in response to the packet transmission request; generating a first encrypted packet for the destination device according to the packet transmission request if the destination device is capable of exchanging encrypted packets; forwarding the first encrypted packet to the destination device via P2P; if the destination device is not capable of exchanging encrypted packets, generating a second encrypted packet according to the packet transmission request, the second encrypted packet including the packet intended for the destination device; and transferring the second encrypted packet to a device that serves as a proxy server via P2P.

6. identifying a device that will be the proxy server; The communication processing method according to claim 5 , further comprising the step of: sending a request to enable a proxy operation to the identified device.

7. obtaining a private key and a public key; Based on a hash value calculated from the public key according to a hash function, determining an IP address; obtaining a digital certificate associated with the public key from a certification authority connected to a network; The communication processing method according to claim 6 , further comprising the step of transmitting the public key and the digital certificate to another device.

8. receiving the public key and a digital certificate associated with the public key from another device, and determining the authenticity of the digital certificate; 8. The communication processing method according to claim 7, further comprising the step of: if the electronic certificate is determined to be valid, determining an IP address of the other device based on a hash value calculated from the public key according to a hash function.

9. a network interface for connecting to a network; a control unit connected to the network interface, The control unit Responding to a packet transmission request, determining whether the destination device is capable of receiving and transmitting encrypted packets; If the destination device is capable of exchanging encrypted packets, generating a first encrypted packet for the destination device in accordance with the packet transmission request; forwarding the first encrypted packet to the destination device via P2P; generating a second encrypted packet including a packet addressed to the destination device in accordance with the packet transmission request if the destination device is capable of exchanging encrypted packets; and transferring the second encrypted packet to a device that serves as a proxy server via P2P.

10. A communication processing program for a computer having a network interface for connecting to a network, the communication processing program causing the computer to execute the communication processing method according to any one of claims 5 to 8 when executed by the computer.

Citation Information

Patent Citations

  • Network system

    JP2018207472A