JP2008288764A - Method for managing file information, and information processing apparatus - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a file information management method for preventing unnecessary file distribution in distributing the file by directly connecting respective nodes in a network system and to provide an information processing apparatus as a node. <P>SOLUTION: In the file information management method for preventing unnecessary file distribution in the distributing the file by directly connecting respective nodes in the network system, each node signs the file and a node receiving the distributed file checks the history of signatures (S14) and determines whether the file is to be received or not by referring to a storage and distribution range of the file (S16) to prevent the unnecessary file distribution. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a method for managing file information in a network system that transmits and receives file information between nodes, and an information processing apparatus as a node constituting a network.

  In recent years, a network having a communication form in which data is freely transmitted and received between arbitrary nodes constituting the network has been actively used.

  A typical form is a form of a communication network called P2P (Peer to Peer). P2P is a network usage mode in which information is directly exchanged between a large number of unspecified nodes, and there are two types: technically requiring the intervention of a central server, and carrying data in a bucket relay manner.

  In such a distributed processing network form, file information is transmitted and received by connecting directly between arbitrary nodes, which improves convenience of communication and is convenient, but exploitation of file information by a third party is possible. There was a tendency that safety risks such as inadvertent data leakage increased.

  There is a possibility that personal information and confidential information may be lost via the network, and even if it is not confidential information, if the data file spreads more than necessary, the contamination range will be spread at the time of virus infection. There is a risk that it may become difficult to take measures when a problem occurs.

  Encrypted communication technology has also been studied in order to ensure security against data leakage in the form of such distributed processing networks. However, even if encryption is performed for each communication to protect confidentiality, it is not possible to prevent file loss itself. Even if it is encrypted, inadvertent leakage can still cause problems.

  A security measure for authenticating a partner node using a signature when directly transmitting and receiving file information between arbitrary nodes has been studied (see Patent Documents 1 and 2).

  Patent Document 1 proposes a technique related to a method for signing data to be communicated. The node that received the signature can confirm the source node. Japanese Patent Application Laid-Open No. 2004-228561 also discloses a technique for adding a signature file to a data file and transmitting the data file. On the receiving side, if the signature cannot be confirmed, the data file is ignored and a warning is given.

  However, in either case, the signature function of confirming the partner node is effective, but only responds with the confirmed result. If the signature is valid, there is no restriction on file distribution, and the file distribution history of how far the file has spread is not involved.

To prevent inadvertent spread of files, these signatures are more closely tied to the sending and receiving of files, and each node systematically signs files and restricts file receipt based on them. For example, it is desirable to use a signature that is associated with the implementation of finer file distribution restrictions.
JP-A-11-65440 JP 2003-218859 A

  As mentioned above, when sending and receiving file information by connecting directly between nodes in a network system, safety risks such as exploitation of file information by third parties and inadvertent data leakage become a problem. It was. Neither encryption nor use of signatures was sufficient from the viewpoint of inadvertent restrictions on file distribution.

  SUMMARY OF THE INVENTION An object of the present invention is to solve the above-mentioned problems and to manage a file information and a node that can prevent unnecessary diffusion of files when file distribution is performed by directly connecting between nodes in a network system. As an information processing apparatus.

  In order to solve the above problems, the present invention has the following features.

  1. A file information management method in a network system for transmitting / receiving file information between nodes, wherein a transmission node encrypts information for specifying the transmission node to a file to be distributed and gives it as a signature And a file distribution step of distributing the file given the signature in the file signature step from the transmission node to the reception node, and from the file distributed in the file distribution step, the reception node performs the file signature step In accordance with a signature authentication step of decrypting the assigned signature and authenticating the transmission node, an authentication result by the signature authentication step, and a predetermined condition that defines a storage / distribution range of the file, the receiving node A receipt decision step for deciding whether to save or discard Method of managing file information that characterized the door.

  2. The receiving node encrypts information for specifying the receiving node and gives it as a signature to the file decided to be saved by the receiving decision step, and the receiving node is newly given as a sending node and the signature is given. 2. The file information management method according to 1, wherein the file is distributed to a new receiving node.

  3. Before the execution of the file distribution step, a security policy granting step for giving a security policy to the file; and before the execution of the receipt decision step, the security policy from the file distributed by the file distribution step A security policy extraction step for extracting the security policy assigned by the assignment step, and in the reception decision step, the file is stored or discarded according to the security policy extracted by the security policy extraction step. 3. The file information management method according to 1 or 2, wherein the file information is determined.

  4). In the reception determination step, the effectiveness of all security policies extracted by the security policy extraction step is determined according to the importance of each node to which each security policy is assigned, and all the effective determinations are made. 4. The file information management method according to 3, wherein whether to save or discard the file is determined according to a security policy.

  5. In the security policy given in the security policy granting step, the work group, storage media, or information on the number of distribution pops for determining the storage / distribution scope of the file to be distributed, and nodes for which storage / distribution is prohibited are specified. 3. The file information management method according to 3 or 4, wherein one or more pieces of information to be included are included.

  6). 6. The method according to any one of 1 to 5, wherein when the number of signatures authenticated in the signature authentication step exceeds a predetermined number, the reception determination step determines to discard the received file. How to manage the file information described.

  7. The signature in the file signing step includes one or more of information specifying a signed node, password information held by the signed node, and information regarding a group to which the signed node belongs. The file information management method according to any one of the above.

  8). 8. The file information according to any one of 1 to 7, wherein in the signature authentication step, the authentication node is inquired about the validity of the extracted signature, and the authentication node returns authentication result information regarding the signed node. Management method.

  9. An information processing apparatus as a node in a network system that sends and receives file information between nodes; a file signature unit that encrypts information for specifying a distribution source node in a file to be distributed, and assigns the signature as a signature; A file distribution unit that distributes the file that has been given a signature by the file signing unit to another node, and a signature that has been given by the file signature unit from the file that has been distributed by the file distribution unit; A signature authentication unit for authenticating a distribution source node, an authentication result by the signature authentication unit, and a reception decision for determining whether to save or discard the file according to a predetermined condition that defines a storage / distribution range of the file And an information processing apparatus.

  10. 10. The information processing apparatus according to 9, wherein the file signing unit encrypts information for specifying a node in the file determined to be stored by the reception determining unit and assigns the information as a signature.

  11. Security policy granting means for giving a security policy to the file; and security policy extraction means for extracting the security policy given by the security policy granting means from the file distributed by the file distribution means, The information processing apparatus according to claim 9 or 10, wherein the reception determining unit determines whether to save or discard the file according to the security policy extracted by the security policy extraction step.

  12 The reception determining unit determines the validity of all security policies extracted by the security policy extracting unit according to the importance of each node to which each security policy is assigned, and determines all the effective policies. 12. The information processing apparatus according to 11, wherein whether to save or discard the file is determined according to a security policy.

  13. In the security policy given by the security policy granting means, information on the work group, storage media, or distribution pop number for determining the storage / distribution range of the file to be distributed, and nodes for which storage / distribution is prohibited are specified. 13. The information processing apparatus according to 11 or 12, wherein one or more pieces of information to be included are included.

  14 Any one of 9 to 13, wherein when the number of signatures authenticated by the signature authentication unit exceeds a predetermined number, the reception determination unit determines to discard the received file. The information processing apparatus described.

  15. The signature by the file signing means includes one or more of information specifying a signed node, password information held by the signed node, and information regarding a group to which the signed node belongs. 9 to 14 The information processing apparatus according to any one of the above.

  16. The information according to any one of claims 9 to 15, wherein the signature authenticating unit inquires an authentication node about the validity of the extracted signature, and acquires authentication result information about the signed node from the authentication node. Processing equipment.

  According to the file information management method and the information processing apparatus as a node according to the present invention, when distributing a file by directly connecting between nodes in a network system, each node signs the file and the distributed node By checking the signature history and deciding whether or not to receive it according to the storage / distribution range of the file, unnecessary spread of the file can be prevented.

  Embodiments according to the present invention will be described below with reference to the drawings.

(Overall network configuration)
FIG. 1 is a diagram showing an example of the overall configuration of a network 1 constituted by a file information management method and an information processing apparatus according to the present embodiment. The overall configuration of the network 1 according to the embodiment of the present invention will be described with reference to FIG.

  A network 1 according to an embodiment of the present invention is configured by nodes such as a plurality of terminal devices 2 (21, 22,..., 2n), a switching hub 3, a router 4, and an authentication server 5, as shown in FIG. LAN (Local Area Network). These terminal devices 2 are connected to the switching hub 3 in a star shape by a twisted pair cable.

  A terminal device 2 as a node constituting a network is an information processing device according to the present invention, and executes data input / output processing with another device such as a personal computer, a workstation, or a printer. It is a device to do. Hereinafter, the term “node” simply refers to this terminal device, and a description will be given assuming that a personal computer as an information processing device is used.

  In the present embodiment, a communication network called P2P (Peer to Peer) is employed. P2P is a network usage mode in which information is directly exchanged between a large number of unspecified nodes, and there are two types: technically requiring the intervention of a central server, and carrying data in a bucket relay manner. Even when a central server is required, the central server only provides a file search database and manages connection of nodes, and exchange of data itself is performed by direct connection between nodes.

  In addition, even if the central server performs central processing as a host, there are systems that can be changed at any time so that any client can function as a central server. There is also a network configuration that can be regarded as having the same function as a P2P system that directly exchanges information.

  In this embodiment, the central server is not used, and the connection topology of FIG. 3 will be described later. However, the nodes (information processing apparatuses) 2 associated in advance are directly connected and communicated. Other nodes are indirectly connected through directly connected nodes. The authentication server (authentication node) 5 is responsible only for management related to the certificate for authentication, and is not directly related to connection for communication. The router 4 is not directly involved in communication between nodes (information processing apparatuses).

  In P2P, since the nodes communicate directly with each other, the security of how to authenticate each other's validity and how to suppress the room for unauthorized entry is important. For this purpose, a digital certificate issued by an authentication server (hereinafter referred to as an authentication node) 5 is used. The authentication node 5 authenticates the node of the submitted digital signature (hereinafter simply referred to as a signature) in response to an inquiry from each node.

  Hereinafter, from the above viewpoint, in the network according to the present embodiment, a method and a node for managing data so that these nodes 2 perform data communication with each other and file information distributed between the nodes is not spread more than necessary. (Information processing apparatus) will be described.

(Configuration of information processing device)
FIG. 2 is a diagram illustrating an example of a hardware configuration of the node (information processing apparatus) 2.

  As shown in FIG. 2, the information processing apparatus 2 includes a CPU 20a, a RAM 20b, a ROM 20c, a hard disk 20d, a communication interface 20e, an image interface 20f, an input / output interface 20g, and other various circuits or devices.

  The communication interface 20e is, for example, a NIC (Network Interface Card), and is connected to one of the ports of the switching hub 3 via a twisted pair cable. The image interface 20f is connected to a monitor and sends a video signal for displaying a screen to the monitor.

  The input / output interface 20g is connected to an input device such as a keyboard or a mouse or an external storage device such as a CD-ROM drive. And the signal which shows the content of operation which the user performed with respect to the input device is input from an input device. Alternatively, data recorded on a recording medium such as a CD-ROM is read by an external storage device and input. Alternatively, data to be written to the recording medium is output to the external storage device.

  The hard disk 20d will be described later with reference to a functional block diagram (FIG. 5), but a connection table holding unit 201, a connection table management unit 202, a data holding unit 203, a data operation unit 204, a signature unit 205, and a security unit 206. , A program and data for realizing the functions of the data receiving unit 207, the data analyzing unit 208, the data creating unit 209, the data transmitting unit 210, and the like are stored. These programs and data are read into the RAM 20b as necessary, and the programs are executed by the CPU 20a.

  Each node 2 is given a host name (machine name), an IP address, and a MAC address as identification information for identifying each other node 2. The host name can be freely assigned by the administrator of the network 1 or the like. The IP address is given according to the rules of the network 1. The MAC address is an address fixedly given to the communication interface 10e of the node 2. Note that another unique ID may be used instead of the MAC address.

  In this embodiment, it is assumed that host names such as “PC1”, “PC2”,... Are assigned to the nodes (information processing apparatuses) 21, 22,. Hereinafter, these nodes 2 may be described by host names.

(Node connection mode)
FIG. 3 is a diagram illustrating an example of a node connection form, that is, a logical topology of the information processing apparatus 2. A connection form of nodes (information processing apparatuses) will be described with reference to FIG.

  As shown in FIG. 3, the node 2 is assumed to be arranged in the virtual space. Then, as indicated by a dotted line, it is associated with at least one other node 2 in the vicinity in the virtual space. And, by these associations, all the nodes 2 are associated directly or indirectly with each other.

  Note that “directly related” means that they are connected by a single dotted line in FIG. 3 (for example, a relationship such as PC1 and PC2 or PC9 in FIG. 3), and “indirectly related”. Means that they are connected by two or more dotted lines and one or more nodes (for example, the relationship between PC1 and PC4 in FIG. 3). Node 2 sends data to other nodes 2 that are directly associated with it.

  FIG. 4 is a diagram showing an example of the connection table TL of the nodes 2 associated as shown in FIG. For each node 2, a list of information for connection with other nodes 2 that are “directly related” and capable of direct data transmission is stored in a table.

  For example, connection tables TL1, TL2, TL6, TL7, TL8, and TL9 as shown in FIG. 4 are held in PC1, PC2, PC6, PC7, PC8, and PC9 in FIG.

(Functions of each part of information processing device)
FIG. 5A is a block diagram illustrating an example of a functional configuration of the node (information processing apparatus) 2. A processing function of each unit of the node 2 will be described with reference to FIG.

  The connection table holding unit 201 stores a connection table TL that shows a list of attributes such as host names, IP addresses, and MAC addresses of other nodes 2 that are directly associated with the node 2 itself. For example, the example of the connection table held in the connection table holding unit 201 of each node has been described with reference to FIG. The contents of these connection tables TL are created in advance by the administrator based on the association of each node 2.

  The connection table management unit 202 manages the connection table TL held in the connection table holding unit 201.

  The data holding unit 203 includes attribute data indicating attributes of the node 2 or the user, data necessary for authentication of the node 2 itself, data used by an operating system (OS) or application software, and user software The data created by, and other various data are stored as files.

  The data operation unit 204 performs processing such as storing data in the data holding unit 203 or updating data stored in the data holding unit 203. For example, the attribute data is updated every time the environment or setting content of the node 2 changes. The data operation unit 204 also performs processing and temporary storage of data (information) acquired from other nodes.

  The signature unit 205 embeds a signature in the file to be distributed. The signature node is authenticated based on the signature embedded in the received file. Whether to receive the file is determined according to the authentication result.

  The security unit 206 distributes the signed file. Assign a security policy to the file to be distributed. It also extracts the security policy from the file.

  The data operation unit 204, the signature unit 205, and the security unit 206 perform data communication with the other nodes 2 of the network 1 via the data reception unit 207 and the data transmission unit 210 as necessary, and connect tables as necessary. The data in the holding unit 201 and the data holding unit 203 is referred to or updated.

  FIG. 5B is a diagram illustrating an internal configuration of functions of the signature unit 205 and the security unit 206. With reference to FIG. 5B, functions of the signature unit 205 and the security unit 206, that is, authentication processing based on signatures with other nodes, and processing functions related to file distribution and restrictions will be described.

  The signature unit 205 includes a file signature unit 205a that applies a signature to the file to be distributed, a signature authentication unit 205b that extracts and decrypts the signature from the file, and authenticates the distribution source node. In addition, a reception determination unit 205c that determines whether to receive a file is included. These are controlled so as to perform the following processing operations.

  For example, the file signature unit 205a encrypts information for identifying its own node with its own private key in a file to be distributed and embeds it as a signature. This causes the receiving node to authenticate its own node that is the distribution source. That is, it functions as a file signature means.

  For example, the signature authenticating unit 205b extracts a signature from the received file, and if the signature node has been authenticated, the signature authenticating unit 205b decrypts the signature using the public key and confirms that the signature has been authenticated. If unauthenticated, the authentication node 5 is inquired for authentication. At the same time, the public key of the node is acquired. That is, it functions as a signature authentication means.

  The reception determining unit 205c determines whether to save or discard the file in accordance with the authentication result of the signature node and a predetermined condition that determines the storage / distribution range of the file. That is, it functions as a reception determination unit.

  The security unit 206 includes a file distribution unit 206a that distributes a signed file, a policy addition unit 206b that assigns a security policy to the file to be distributed, and a policy extraction unit 206c that extracts a security policy from the distributed file. It is. These are controlled so as to perform the following processing operations.

  The file distribution unit 206a distributes the signed file to other nodes. That is, it functions as a file distribution means.

  The policy assigning unit 206b assigns a security policy to the file to be distributed. The security policy is a condition for defining a storage / distribution range of a file for safety. That is, it functions as a security policy giving means.

  The policy extraction unit 206c extracts a security policy from the received file. In response to this, the file distribution range is limited. The policy extraction unit 206c functions as a security policy extraction unit.

  Details of each processing in the signature unit 205 and the security unit 206 will be described in the description of the file distribution management flow described later.

  Returning to FIG. 5A, the description of each part of the node (information processing apparatus) 2 will be continued.

  The data receiving unit 207 performs control processing for performing data communication with other nodes 2. The data receiving unit 207 receives a packet necessary for the node 2 among the packets flowing through the network 1.

  The data analyzing unit 208 extracts necessary information from the received data received by the data receiving unit 207 and analyzes the contents thereof, thereby determining the type of the received data.

  The data creation unit 209 creates transmission data to be transmitted to another node 2 based on an instruction from the data operation unit 204, the signature unit 205, the security unit 206, or the like.

  The data transmission unit 210 transmits the packetized transmission data generated by the transmission data creation unit 209 to the other nodes 2.

(Management of file distribution)
As described above, the node 2 in the present embodiment applies a signature that can identify the distribution source and distributes the file information with the node 2 that is directly or indirectly associated with the node 2. . In addition, a signature is extracted from the distributed file, authenticated, and whether to receive the file is determined depending on whether a predetermined condition is satisfied.

  Thus, management is performed so as to limit the scope of file storage and distribution. In addition, when signing a file, by assigning a security policy if necessary, it is possible to arbitrarily control the restricted range of file storage and distribution.

  FIG. 6 is a flowchart showing the flow of management of the file distribution. With reference to FIG. 6, a schematic flow of management of file distribution range restrictions will be described.

  Step S11 in FIG. 6 is a file signature process, in which information for specifying its own node is encrypted with its own private key in a file to be distributed and embedded as a signature.

  Step S12 is a security policy assigning step, which assigns a security policy, which is a condition for determining the storage / distribution range of the file for safety, to the file to be distributed.

  Step S13 is a file distribution process in which the signed file is distributed to other nodes.

  Step S14 is a signature authentication step, where a signature is extracted from the received file. If the signature node has been authenticated, the signature is decrypted using the public key to confirm that it has been authenticated.

  Step S15 is a security policy extraction step for extracting a security policy for limiting the storage / distribution range of the file from the received file.

  Step S16 is a reception decision step, and decides whether to save or discard the file according to the authentication result of the signature node and a predetermined condition (security policy) that defines the storage / distribution range of the file.

  If you save the file, you may want to redistribute it. That is, returning to step S11, the above flow is repeated, the file is signed, a security policy is assigned, and redistribution is performed. If the above flow is repeated, it may be redistributed over and over again.

  For file distribution between nodes, for example, it is desirable to collectively transmit the data file, signature, security policy, and the like according to a protocol called SOAP (Simple Object Access Protocol).

  The following is the management of file distribution range restrictions. A more detailed flow example will be described.

<Example 1 of file distribution management flow>
FIG. 7 shows an example of a specific processing flow of the flow of FIG. However, the security policy assigning step and the security policy extracting step are omitted, and the conditions for determining the storage / distribution range of the file are determined in advance.

  FIG. 8A shows a state in which the file 1 is distributed from the node (PC1) to the node (PC2) and the node (PC3) according to the flow of FIG. 7, and FIG. Shows the node settings.

  A file distribution management flow example 1 will be described with reference to FIGS.

  First, step S101 is a file signature process, in which the file signature unit 205a signs a file to be distributed.

  Step S104 is a file distribution process, in which the file distribution unit 206a distributes the signed file to other nodes. In FIG. 8, the file 1 in which the signature of the PC 1 is embedded is distributed from the node (PC 1) to the node (PC 2) and the node (PC 3).

  In step S200, the distributed file is received. That is, PC2 and PC3 receive file 1 distributed from PC1.

  Steps S201 and S203 are a signature authentication process. The signature authentication unit 205b extracts a signature from the received file, and if the signature node is authenticated, the signature is decrypted using the public key and authenticated. Make sure that That is, in FIG. 8, PC2 and PC3 respectively extract the signature of PC1 of file 1 and confirm that it has been authenticated. If not authenticated, each authentication node 5 is inquired for authentication. At the same time, the public key of the node is acquired.

  If the signature authentication is OK in step S203 (step S203: YES), step S204a is executed. If the signature authentication is not OK (step S203: NO), the process proceeds to step S207, and the reception of the file is rejected. In step S209, the file is discarded.

  In step S204a, the reception determining unit 205c refers to the result of the signature authentication and confirms whether or not a predetermined storage / distribution condition is satisfied. Here, it is assumed that the storage / distribution condition is determined to belong to the same work group as the distribution source node in the setting as shown in FIG.

  If it is the same work group in step S205a (step S205a: YES), step S206 is executed to receive the file. In step S208, the file is saved. If they are not the same work group (step S205a: NO), step S207 and step S209 are executed. That is, the file is rejected and the file is discarded. Accordingly, the steps subsequent to step S204a are the reception determination process.

  In the case of FIG. 8, PC2 and PC3 respectively specify that PC1 is workgroup A from the signature of PC1, and PC2 receives file 1 because it is the same workgroup A as the distribution source PC1. And save. Since PC3 is a work group Z different from the distribution source PC1, the reception of the file 1 is rejected and discarded.

  In this way, the distribution restriction is performed so that the file is not spread to a node that is not the same work group as the distribution source node.

<Example 2 of file distribution management flow>
FIG. 9 shows a management flow example 2 of file distribution. However, as in the management flow example 1, the security policy applying step and the security policy extracting step are omitted. The difference from the management flow example 1 is that the node that receives the file redistributes the file.

  In FIG. 10A, in accordance with the flow of FIG. 9, from the node (PC1) to the node (PC2), from the node (PC2) to the node (PC3), and from the node (PC3) to the node (PC4). FIG. 10B shows how the file 1 is sequentially redistributed, and FIG. 10B shows the setting of each node at that time.

  A file distribution management flow example 2 will be described with reference to FIGS. However, the description of the same steps as those in the management flow example 1 will be simplified.

  First, step S105 is a step including step S101 and step S104 of the management flow example 1. That is, it is a file signature process and a file distribution process. In FIG. 10, first, the file 1 in which the signature of the PC 1 is embedded is distributed from the node (PC 1) to the node (PC 2).

  In step S202 and step S203, the distributed file is received, and the same signature authentication process as in the management flow example 1 is executed. That is, in FIG. 10, the PC 2 extracts the signature of the PC 1 of the file 1 and confirms that it has been authenticated.

  If the signature authentication is OK (step S203: YES) in step S203, the next step S204a is executed. If the signature authentication is not OK (step S203: NO), the process proceeds to step S207 to receive the file. The rejection is the same as in the first management flow example.

  The reception determination process after step S204a is the same as that in the management flow example 1. Here, since the PC 2 is the same work group A as the distribution source PC 1, the file 1 is received in step S206. If it is a different work group, the reception of file 1 is rejected in step S207.

  When the file 1 is received in step S206, the file signature unit 205a signs and saves the file in step S208. The reason for applying the signature is that it becomes a distribution source and redistributes the file. That is, step S208 is a file signature process. In FIG. 10, the signature is applied by the PC 2, and the file 1 has the signatures of the PC 1 and the PC 2.

  If the reception of file 1 is rejected in step S207, the file is discarded in step S209. Of course, there is no further redistribution. The process ends.

  The file signed in step S208 refers to redistribution conditions (hop count) for redistribution in step S212. The number of hops indicates how many nodes have been distributed from the first distribution source. In other words, this is the number of redistributions, and can be obtained from the number of signatures attached to the file each time redistribution.

  In this example, it is determined that the number of pops is 4 in advance, but PC 2 in FIG. 10 still has 1 hop and can be redistributed.

  If the redistribution condition is satisfied (step S212: YES), step S217 is executed. Step S217 is a file distribution process. If the redistribution condition is not satisfied (step S212: NO), the redistribution is not performed. The process ends. In this case, it is preferable to delete the file signature.

  The redistribution condition reference in step S212 may be performed not only before the distribution of such a file but also in the reception determination process after step S204a. In that case, you will refuse to accept what has been redistributed.

  In the case of FIG. 10, the PC 2 redistributes the PC 1 and the file 1 with the signature of the PC 2 to the PC 3. Thereafter, the PC 3 repeats the steps after step S202, and the PC 1 and the PC 2 and the file 1 with the signature of the PC 3 are redistributed to the PC 4 again. Files are redistributed from PC1 to PC5, which are the same work group A, with increasing signatures each time. However, since the PC 5 already has 4 hops, no further redistribution is performed.

  In this way, even if the files are sequentially redistributed from the distribution source node, the files will not spread beyond the same workgroup range or via a predetermined number of nodes. Distribution restrictions are enforced.

<Example 3 of file distribution management flow>
FIG. 11 shows a management flow example 3 of file distribution. However, the difference from the management flow example 1 is that it includes a security policy applying step and a security policy extracting step. The conditions for the storage / distribution range of the file are not predetermined, but are assigned as a security policy in the management flow.

  FIG. 12A shows how the file 1 is distributed from the node (PC1) to the node (PC2) and the node (PC3) according to the flow of FIG. 11, and FIG. 12B shows each node at that time. Shows the settings.

  A file distribution management flow example 3 will be described with reference to FIGS. 11 and 12. However, the description of the same steps as those in the management flow example 1 will be simplified.

  First, step S101 is a file signature process similar to that in the management flow example 1.

  Step S102 is a security policy assigning step, in which the policy assigning unit 206b assigns a security policy to the signed file. In FIG. 12, a security policy A is assigned. The condition of the security policy A is “file data should not be copied or moved to a removable medium or a node outside the group, and stored on an encrypted hard disk”.

  Step S104 is a file distribution process similar to that in the management flow example 1. In FIG. 12, the file (1) in which the signature of PC1 is embedded and the security policy A is assigned is distributed from the node (PC1) to the node (PC2) and the node (PC3).

  In step S200, the distributed file is received as in the management flow example 1. That is, PC2 and PC3 each receive file 1 distributed from PC1.

  Step S201 and step S203 are also a signature authentication step, as in the management flow example 1. That is, in FIG. 12, PC2 and PC3 each extract the signature of PC1 of file 1 and confirm that it has been authenticated.

  If the signature authentication is OK in step S203 (step S203: YES), step S204 is executed. If the signature authentication is not OK (step S203: NO), the process proceeds to step S207, and the reception of the file is rejected. In step S209, the file is discarded. This is the same as the management flow example 1.

  Step S204 is a security policy extraction step, in which the policy extraction unit 206c extracts the security policy assigned to the file. Check whether the extracted security policy is satisfied by referring to the result of the above signature authentication. Here, it is determined whether or not the above-described security policy A is satisfied with the settings shown in FIG.

  If the security policy is satisfied in step S205 (step S205: YES), step S206 is executed to receive the file. In step S208, file saving is executed. If the security policy is not satisfied (step S205: NO), step S207 and step S209 are executed. That is, the file is rejected and the discard is executed. Therefore, the steps subsequent to step S204 are the reception determination process.

  In the case of FIG. 12, the PC 2 is the same work group A as the distribution source PC 1, but is based on a removable medium and does not satisfy the security policy A without an encryption function for storage. Therefore, the PC 2 refuses to receive the file 1 and discards it.

  The PC 3 satisfies the security policy A because it is the same work group A as the distribution source PC 1 and includes a hard disk that can be encrypted and stored. Therefore, the PC 3 receives and stores the file 1.

  In this way, the distribution source node sets the security policy as appropriate, adjusts the storage and distribution range of the file, and restricts distribution so that the file will not spread to nodes with safety concerns. Can do.

<Example 4 of file distribution management flow>
FIG. 13 shows a management flow example 4 for file distribution. However, similarly to the management flow example 3, it includes a security policy applying step and a security policy extracting step. The difference from the management flow example 3 is that the node receiving the file redistributes the file.

  In FIG. 14A, in accordance with the flow of FIG. 13, from the node (PC1) to the node (PC2), from the node (PC2) to the node (PC3), and from the node (PC3) to the node (PC4). FIG. 14B shows how the file 1 is sequentially redistributed, and FIG. 14B shows the setting of each node at that time.

  A file distribution management flow example 4 will be described with reference to FIGS. However, the description of steps similar to those in the management flow examples 1 to 3 will be simplified.

  First, step S103 is a step including step S101 and step S102 of the management flow example 3. That is, it is a file signature process and a security policy provision process. In FIG. 14, first, the signature of PC 1 is embedded in file 1 and security policy A is given.

  The security policy A here is “file data is not copied or moved to a removable medium or a node outside the group, and a file that has passed through a node described in the latest rejection list is not received”.

  Step S104 is a file distribution process similar to that in the management flow example 3. In FIG. 14, the file 1 to which the signature of the PC 1 is embedded and the security policy A is attached is distributed from the PC 1 to the PC 2.

  In step S202 and step S203, the distributed file is received, and a signature authentication process similar to that in the management flow example 2 is executed. That is, in FIG. 14, the PC 2 extracts the signature of the PC 1 of the file 1 and confirms that it has been authenticated.

  If the signature authentication is OK (step S203: YES) in step S203, the next step S204 is executed. If the signature authentication is not OK (step S203: NO), the process proceeds to step S207 to receive the file. The rejection is the same as in the third management flow example.

  Step S204 is a security policy extraction step as in the management flow example 3, and the policy extraction unit 206c extracts a security policy attached to the file. Here, it is determined whether or not the above-described security policy A is satisfied with the settings shown in FIG.

  The reception determination process after step S204 is the same as in the management flow example 3. However, the content of the security policy A is different from the management flow example 3. Therefore, in step S205b, it is determined whether or not there is a signature of a file that has already been verified for authentication that is included in the latest rejection list (CRL). The rejection list is a list of nodes that have been authenticated but canceled.

  If there is nothing in the latest rejection list (CRL) (step S205b: YES), step S206 is executed and the file 1 is received. If there is anything in the latest refusal list (CRL) (step S205b: NO), step S207 is executed and the receipt of the file 1 is refused.

  In FIG. 14, PC1 is not listed in the latest rejection list (CRL), and file 1 is received by PC2.

  When the file 1 is received in step S206, the file signature unit 205a signs and saves the file in step S208. The reason for applying the signature is that it becomes a distribution source and redistributes the file. That is, step S208 is a file signature process. Here, the signature is applied by the PC 2 and the file 1 has the signatures of the PC 1 and the PC 2.

  If the reception of file 1 is rejected in step S207, the file is discarded in step S209. Of course, there is no further redistribution. The process ends.

  In step S213, it is determined whether the file signed in step S208 is to be redistributed. In the case of redistribution (step S213: YES), step S217 is executed. Step S217 is a file distribution process. If not redistributed (step S213: NO), the process is terminated without redistribution.

  In the case of FIG. 14, the PC 2 redistributes the PC 1 and the file 1 with the signature of the PC 2 to the PC 3. Thereafter, the PC 3 repeats the steps after step S202, and the PC 1 and the PC 2 and the file 1 with the signature of the PC 3 are redistributed to the PC 4 again. Files are redistributed from PC1 to PC5, which are the same work group A, with increasing signatures each time.

  However, in the case of FIG. 14, when the PC 5 receives the file 1, the PC 3 is newly described in the latest rejection list (CRL). The PC 5 confirms this in the reception determination process after step S204. Since it is described in the latest rejection list (CRL) (step S205b: NO), step S207 is executed, and reception of the file 1 is rejected.

  In this way, even if the distribution source node sets the security policy as appropriate and the files are redistributed sequentially, the latest deny list is referenced each time, and the nodes listed in the list, that is, unauthenticated If there is a history via, distribution can be restricted so that the file will not spread further.

  By tracing the signature information, the file distribution / diffusion path can also be specified, and other inconvenient nodes can be detected.

<Example 5 of file distribution management flow>
FIG. 15 shows a management flow example 5 of file distribution. However, it is almost the same as the management flow example 4. The difference is that a security policy is added before the file is redistributed.

  FIG. 16A shows a state in which the file 1 is sequentially redistributed from the node (PC1) to the node (PC2) and further from the node (PC2) to the node (PC3) according to the flow of FIG. FIG. 16B shows the setting of each node at that time.

  A file distribution management flow example 5 will be described with reference to FIGS. 15 and 16. However, the description of the same steps as those in the management flow example 4 will be simplified.

  Step S103 is the same as that in the management flow example 4. That is, it is a file signature process and a security policy provision process. In FIG. 16, the signature of PC 1 is first embedded in file 1 and security policy A is given.

  The security policy A here is “Do not copy or move file data to removable media and nodes outside the group”.

  Step S104 is also a file distribution process similar to the management flow example 4. In FIG. 16, the file 1 in which the signature of the PC 1 is embedded and the security policy A is attached is distributed from the PC 1 to the PC 2.

  In step S202 and step S203, similarly to the management flow example 4, the distributed file is received and the signature authentication process is executed. That is, in FIG. 16, the PC 2 extracts the signature of the PC 1 of the file 1 and confirms that it has been authenticated.

  If the signature authentication is OK in step S203 (step S203: YES), the next step S204 is executed. If the signature authentication is not OK (step S203: NO), the process proceeds to step S207 to receive the file. The rejection is the same as in the management flow example 4.

  Step S204 is a security policy extraction step as in the management flow example 4, and the policy extraction unit 206c extracts the security policy assigned to the file.

  The reception determination process after step S204 is the same as in the management flow example 4. However, here, it is assumed that PC 2 (also PC 3) satisfies the security policy A with the settings shown in FIG.

  If the security policy A is satisfied (step S205: YES), step S206 is executed and the file 1 is received. If the security policy A is not satisfied (step S205: NO), step S207 is executed and the receipt of the file 1 is rejected.

  In FIG. 16, PC2 satisfies security policy A, and file 1 is received by PC2.

  When the file 1 is received in step S206, the file signature unit 205a signs and saves the file in step S208. This is the same as the management flow example 4, that is, step S208 is a file signature process.

  The case of rejecting the reception of the file 1 in step S207 is the same as in the management flow example 4. In step S209, the file is discarded, and the process ends.

  In step S214, it is determined whether or not the file signed in step S208 is to be redistributed. However, the security policy regarding redistribution is also confirmed here. For example, as will be described later, when the number of nodes that can be redistributed (for example, the number of hops described above) is defined in the security policy, it is also determined whether or not the redistribution to be performed satisfies the condition.

  If the redistribution condition is satisfied (step S214: YES), step S215 is executed. If the redistribution condition is not satisfied (step S214: NO), the process is terminated without redistribution.

  In step S215, it is determined whether to add a security policy at this point. When adding a security policy (step S215: YES), step S216 is executed. If a security policy is not added (step S215: NO), the process proceeds to step S217.

  Step S216 is a security policy assigning step, in which a new security policy is added and assigned. Here, it is assumed that in addition to the security policy A, a new security policy B (“redistribution from here up to one node”) is added.

  Step S217 is a file distribution process. In the case of FIG. 16, the PC 2 redistributes the PC 1 and the file 1 with the signature of the PC 2 to which the security policy B is added to the PC 3.

  Thereafter, the PC 3 repeats the steps after step S202. However, in the case of FIG. 16, the situation changes when the PC 3 receives the file 1 and tries to redistribute it in step S214.

  When the PC 3 confirms the security policy to determine redistribution, a security policy B “Redistribution from here up to one node” is newly added by the redistribution source PC 2. Therefore, when the PC 3 performs redistribution, the limit of one node is exceeded. Therefore, it is determined that redistribution is not possible (step S214: NO), and the process ends without redistribution.

  Note that the security policy confirmation in step S214 may be performed not only before the distribution of such a file, but also in the reception decision process after step S204. In that case, the redistributed file will be rejected.

  In this way, even if files are sequentially redistributed to the security policy assigned by the distribution source node, by adding a new security policy in the middle, considering the situation each time, You can also adjust the storage and distribution scope of files as appropriate.

<Example 6 of file distribution management flow>
FIG. 17 shows a management flow example 6 of file distribution. However, it is almost the same as the management flow example 5. The difference is that when checking the security policy, the effectiveness of each of the plurality of security policies is evaluated and the security policy is selectively checked.

  In FIG. 18A, the file 1 is sequentially redistributed from the node (PCA1) to the node (PCA) and further from the node (PCA) to the node (PCA2) and the node (PCB) according to the flow of FIG. Show how it goes. FIG. 18B shows the setting of each node at that time. PCA, PCB, and PCC are the core nodes of work groups A, B, and C, respectively, and PCA1, PCA2, PCB1, and PCC1 are the respective groups. It is a normal node.

  A file distribution management flow example 6 will be described with reference to FIGS. 17 and 18. However, the description of the same steps as those in the management flow example 5 will be simplified.

  First, step S106 is a step including step S103 and step S104 of the management flow example 5. That is, a file signature process, a security policy application process, and a file distribution process.

  In FIG. 18, the file 1 in which the signature of the PCA 1 is embedded and the security policy A is assigned is distributed from the PCA 1 to the PCA which is the basic node of the same group. The security policy A here is “distribution up to one node”.

  Step S202 and step S203 are also similar to the management flow example 5, and the signature authentication process is executed. That is, in FIG. 18, the PCA extracts the signature of PCA1 of file 1 and confirms that it has been authenticated.

  If the signature authentication is OK in step S203 (step S203: YES), the next step S204b is executed. If the signature authentication is not OK (step S203: NO), the process proceeds to step S207 to receive the file. The rejection is the same as in the fifth management flow example.

  Step S204b is a security policy extraction step, in which the policy extraction unit 206c extracts the security policy assigned to the file. However, in this flow example, when there are a plurality of security policies, the validity determination is performed, which will be described later.

  The reception determination process after step S204c is the same as in the management flow example 5. Here, the security policy evaluated in step S204b is confirmed. However, for the PCA of FIG. 18, the security policy is only A, and the PCA satisfies the security policy A (“distribution is up to one node”) based on the setting of FIG.

  If the security policy A is satisfied (step S205: YES), step S206 is executed and the file 1 is received. If the security policy A is not satisfied (step S205: NO), step S207 is executed and the receipt of the file 1 is rejected. This is also the same as the management flow example 5.

  Step S208 is also similar to the management flow example 5, that is, a file signature process. As in the management flow example 5, in step S209, the file is discarded, and the process ends.

  In step S214, it is determined whether or not the file signed in step S208 is to be redistributed. However, here, as shown in FIG. 18, it is assumed that the PCA, which is the core node, decides to add a new security policy in consideration of redistribution to other groups.

  The PCA that has decided to redistribute to another group (step S214: YES) executes step S215. If it is determined not to redistribute (step S214: NO), the process is terminated without redistribution.

  Step S215 is the same as the management flow example 5. For PCA, when a security policy is added (step S215: YES), step S216 is executed.

  Step S216 is also a security policy assigning step as in the management flow example 5, and a new security policy is added and assigned in consideration of redistribution to other groups. Here, it is assumed that in addition to the security policy A, a new security policy B (“redistribution to the core node is unlimited”) is added by the PCA.

  Step S217 is a file distribution process. In the case of FIG. 18, the PC 2 redistributes the PCA 1 and the PCA signed file 1 to which the security policy B is added to the PCA 2 and the PCB.

  Thereafter, each of PCA2 and PCB repeats the steps after step S202. However, in the case of FIG. 18, the situation changes when the PCA 2 or PCB receives the file 1 and authenticates it and confirms whether the security policy extracted in step S204b and thereafter is satisfied.

  There are two extracted security policies, A and B. A is “distribution is limited to one node” and B is “unredistribution to core nodes is unlimited”. The two are not consistent. On the other hand, in step S204b, the validity is evaluated according to the importance of the signature node to which each policy is assigned.

  Of these, A is assigned by the normal node (PCA1), and B is assigned by the backbone node (PCA). The policy B assigned by the PCA is determined to be effective and prioritized from the importance of the basic node. That is, “redistribution to the core node is unlimited”, and therefore policy A is interpreted as “up to one node for distribution (to nodes other than the core node)”.

  In step S204c, it is confirmed whether the security policy is satisfied according to this. Consider the case of PCA2 and PCB in FIG.

  As for PCA2, it is going to be redistributed to another normal node, for example, PCA3, but this is also a normal node, and distribution to the normal node becomes impossible because it exceeds 1 node, and it will be rejected by PCA3. become.

  The PCB is being redistributed to another normal node (PCB1) and another backbone node (PCC), and both are distributed and received. This is because the PCB itself is a core node, and therefore, redistribution to the normal node (PCB1) does not exceed one node, and redistribution to the core node (PCC) is also unlimited.

  The same is true for the next redistribution from PCB2 and PCC. As shown in FIG. 18, due to the evaluation of the effectiveness of the security policies A and B, redistribution from the PCB 2 to another normal node (PCB 3) becomes impossible, and file reception is rejected. Redistribution from the PCC to another normal node (PCC1) is possible. Of course, it can be redistributed to another core node (PCD).

  In this way, even if files are sequentially redistributed to the security policy assigned by the distribution source node, a new security policy can be added in the middle of the process, and these policies can be added. By evaluating the effectiveness according to the importance of each added node, it is possible to adjust the storage and distribution scope of finer-grained files.

  As described above, according to the file information management method and the information processing apparatus as a node according to the present embodiment, each node signs a file when distributing the file by directly connecting the nodes in the network system. , And the distributed node confirms the signature history and decides whether or not to receive it according to the storage / distribution range of the file, thereby preventing unnecessary spread of the file.

  The scope of the present invention is not limited to the above embodiment. Unless it deviates from the meaning of this invention, those changed forms are also included in the range.

1 is a diagram illustrating an example of the overall configuration of a network 1. FIG. 2 is a diagram illustrating a hardware configuration example of an information processing apparatus 2 as a node configuring a network 1. FIG. It is a figure which shows the example of the connection form of each node 2 which comprises the network 1, ie, the logical topology of a node. It is a figure which shows the connection table TL example of the node 2 linked | related like FIG. FIG. 2 is a block diagram (a) illustrating an example of a functional configuration of the information processing apparatus 2 as a node, and a diagram (b) illustrating an internal configuration of functions of a signature unit 205 and a security unit 206. 3 is a flowchart showing a flow of file distribution management between nodes 2 constituting a network 1; 10 is a flowchart illustrating a first example of a file distribution management flow. It is a figure for demonstrating a mode that a file is distributed according to FIG. 10 is a flowchart showing a second example of a file distribution management flow. It is a figure for demonstrating a mode that a file is distributed according to FIG. 10 is a flowchart showing a third example of a file distribution management flow. It is a figure for demonstrating a mode that a file is distributed according to FIG. 15 is a flowchart showing a file distribution management flow example 4; It is a figure for demonstrating a mode that file distribution is performed according to FIG. 10 is a flowchart illustrating a fifth example of a file distribution management flow. It is a figure for demonstrating a mode that a file is distributed according to FIG. 15 is a flowchart showing a management example 6 of file distribution. It is a figure for demonstrating a mode that a file is distributed according to FIG.

Explanation of symbols

1 Network (P2P)
2 Information processing device (node)
3 Switching hub 4 Router 5 Authentication server (authentication node)
DESCRIPTION OF SYMBOLS 201 Connection tape holding part 202 Connection table management part 203 Data holding part 204 Data operation part 205 Signature part 205a File signature part 205b Signature authentication part 205c Receipt determination part 206 Security part 206a File distribution part 206b Policy grant part 206c Policy extraction part 207 Data Reception unit 208 Data analysis unit 209 Data creation unit 210 Data transmission unit TL connection table

Claims (16)

A file information management method in a network system for transmitting and receiving file information between nodes,
A file signing step in which a transmission node encrypts information for identifying the transmission node in a file to be distributed and gives it as a signature;
A file distribution step of distributing the file given the signature in the file signature step from the transmission node to the reception node;
A signature authenticating step in which the receiving node decrypts the signature given by the file signature step from the file distributed in the file distribution step, and authenticates the transmitting node;
A reception determination step for determining whether the reception node stores or discards the file in accordance with an authentication result obtained by the signature authentication step and a predetermined condition that defines a storage / distribution range of the file. A featured file information management method. The receiving node encrypts information for identifying the receiving node and gives it as a signature to the file determined to be stored by the receiving determination step,
2. The file information management method according to claim 1, wherein the receiving node distributes the file with the signature to the new receiving node as a new transmitting node. A security policy giving step for giving a security policy to the file before the file distribution step is executed;
A security policy extraction step for extracting the security policy assigned by the security policy grant step from the file distributed by the file distribution step before the reception determination step is executed;
In the receipt determination step,
3. The file information management method according to claim 1, wherein whether to save or discard the file is determined according to the security policy extracted by the security policy extraction step. In the receipt determination step,
The effectiveness of all security policies extracted by the security policy extraction step is determined according to the importance of each node to which each security policy is assigned,
4. The file information management method according to claim 3, wherein whether to save or discard the file is determined according to all security policies determined to be valid. In the security policy given in the security policy granting step,
It includes at least one of information on a work group, a storage medium, or a distribution pop number for determining a storage / distribution range of the file to be distributed, and information for specifying a node for which storage / distribution is prohibited. The file information management method according to claim 3 or 4. When the number of signatures authenticated in the signature authentication process exceeds a predetermined number,
6. The file information management method according to claim 1, wherein in the reception determination step, the received file is determined to be discarded. In the signature in the file signature process,
7. The information according to claim 1, further comprising at least one of information for identifying a signed node, password information held by the signed node, and information regarding a group to which the signed node belongs. File information management method. In the signature authentication step,
8. The file information management method according to claim 1, wherein the authenticity of the extracted signature is inquired to an authentication node, and the authentication node returns authentication result information regarding the signed node. An information processing apparatus as a node in a network system that transmits and receives file information between nodes,
A file signing means for encrypting information for identifying a distribution source node in a file to be distributed and giving it as a signature;
File distribution means for distributing the file that has been signed by the file signing means to other nodes;
A signature authenticating means for authenticating a distribution source node by decrypting a signature given by the file signing means from a file distributed by the file distributing means;
Receiving determination means for deciding whether to save or discard the file in accordance with an authentication result by the signature authenticating means and a predetermined condition that defines a storage / distribution range of the file. apparatus. The file signing means includes
The information processing apparatus according to claim 9, wherein information for specifying a node is encrypted and added as a signature to the file determined to be stored by the reception determination unit. Security policy giving means for giving a security policy to the file;
Security policy extraction means for extracting the security policy assigned by the security policy assignment means from the file distributed by the file distribution means,
The receipt determining means includes
The information processing apparatus according to claim 9 or 10, wherein the information processing apparatus determines whether to save or discard the file according to a security policy extracted by the security policy extraction step. The receipt determining means includes
The effectiveness of all security policies extracted by the security policy extraction means is determined according to the importance of each node to which each security policy is assigned,
12. The information processing apparatus according to claim 11, wherein whether to save or discard the file is determined according to all security policies determined to be valid. In the security policy granted by the security policy granting means,
It includes at least one of information on a work group, a storage medium, or a distribution pop number for determining a storage / distribution range of the file to be distributed, and information for specifying a node for which storage / distribution is prohibited. The information processing apparatus according to claim 11 or 12. When the number of signatures authenticated by the signature authentication means exceeds a predetermined number,
The information processing apparatus according to claim 9, wherein the reception determination unit determines to discard the received file. In the signature by the file signing means,
15. The information according to claim 9, further comprising at least one of information for identifying a signed node, password information held by the signed node, and information regarding a group to which the signed node belongs. Information processing device. The signature authentication means includes
The information processing apparatus according to any one of claims 9 to 15, wherein an authentication node is inquired about the validity of the extracted signature, and authentication result information regarding the signed node is acquired from the authentication node.

Images