JP5518158B2 - Data verification apparatus and program - Google Patents

Description

  The present invention relates to a technique for dealing with malware.

In recent years, accidents in which malware leaks confidential information outside the organization have become a problem.
Cyber attacks using malware have become sophisticated, and in attacks called Advanced Persistent Threat (hereinafter referred to as “APT”) shown in Non-Patent Document 1, malware that has invaded an organization via email attachments etc. Infected, it communicates with a command & control server (hereinafter referred to as “C & C server”) on the Internet operated by the attacker, downloads new malware and attack tools, and updates itself.
The malware then scouts the organization, finds the file server, and leaks the confidential file to the C & C server.
The communication that Malware uses for communication with the C & C server and file leakage is generally HTTP (HyperText Transfer Protocol), which is a protocol that is permitted between the organization and the Internet, and file leakage is often POST.
In APT, the malware captures the screen of the user's computer and sends it to the C & C server, and the attacker may observe what the user is performing by observing the screen capture.
Also, in response to an instruction from the C & C server, the malware may perform an operation such as searching for a file and moving the file.
In this way, cyber attacks on organizations in recent years have become sophisticated and there is no definitive countermeasure.

As a countermeasure for information leakage of files to the Internet, there is a technique described in Non-Patent Document 2.
In the present technology, it is detected that a file is about to be transmitted outside the organization, and whether or not transmission is possible is determined based on whether or not the information of the file is registered in the distribution permission list.

Design and operation guide for countermeasures against "new types of attacks", revised 2nd edition, IPA Proposal of node type information distribution prevention function in P2P file exchange software environment, Matsuoka et al., 2008-CSEC-42

In the technique described in Non-Patent Document 2, the user needs to register information on a file that can be disclosed in advance in the distribution permission list, and further needs to add / delete information on a file that can be disclosed and maintain it constantly. is there.
In addition, a specific method such as using GUI (Graphical User Interface) is not described as a method for registering file information in the distribution permission list.
In recent cyber attacks, as described above, the attacker operates the malware after observing the user's operation and understanding what kind of processing is being performed. There is a possibility of leaking the file by registering the information of the file to be leaked in the distribution permission list.

  The present invention has been made in view of the circumstances as described above, and has as its main object to prevent information leakage by malware or an unauthorized user without registering information on a file that can be made public.

The data verification device according to the present invention is:
A communication data receiving unit that receives communication data including verification target data to be verified;
Verifying whether the verification data used for verifying that the verification target data is not data illegally operated by at least one of malware and an unauthorized user is included in the communication data; A data verification unit that verifies that the verification target data is not illegally operated data using the verification target data and the verification information,
Communication data transfer for excluding the verification information from the communication data and transferring the communication data excluding the verification information when the data verification unit determines that the verification target data is not illegally operated data Part.

According to the present invention, the verification information is included in the communication data, and the verification information is included in the communication data, and the verification information is excluded from the communication data only when the verification information includes the verification information. Transfer data.
For this reason, it is possible to prevent information leakage by malware or an unauthorized user without registering information of a file that can be opened.

FIG. 3 shows a configuration example of a terminal apparatus according to the first embodiment. FIG. 4 is a flowchart showing an operation example of a check processing unit according to the first embodiment. FIG. 3 is a flowchart showing a procedure for generating check data according to the first embodiment. FIG. 3 is a flowchart showing a procedure for generating check data according to the first embodiment. FIG. 3 is a diagram illustrating a configuration example of an inspection server device according to the first embodiment. FIG. 3 is a flowchart showing an operation example of the inspection server device according to the first embodiment. FIG. 4 is a flowchart showing a procedure for verifying verification data according to the first embodiment. FIG. 4 is a flowchart showing a procedure for verifying verification data according to the first embodiment. 1 is a diagram showing an outline of a communication system according to Embodiment 1. FIG. FIG. 4 is a diagram showing an example of a check processing screen according to the first embodiment. The figure which shows the example of the file with a check which concerns on Embodiment 1. FIG. FIG. 6 shows a configuration example of a terminal apparatus according to Embodiment 2. FIG. 9 is a flowchart showing an operation example of a check processing unit according to the second embodiment. FIG. 9 shows a configuration example of a terminal apparatus according to Embodiment 3. FIG. 9 is a flowchart showing an operation example of a marking processing unit according to the third embodiment. FIG. 9 is a flowchart showing an operation example of a check processing unit according to the fourth embodiment. FIG. 10 is a diagram illustrating an example of a system configuration according to a fourth embodiment. FIG. 10 is a diagram illustrating an example of a check processing screen according to a fifth embodiment. The figure which shows the example of the file with a check which concerns on Embodiment 5. FIG. FIG. 6 shows a configuration example of a terminal apparatus according to Embodiment 5. FIG. 10 is a diagram illustrating a configuration example of a marking addition unit according to a sixth embodiment. FIG. 10 is a diagram illustrating a configuration example of an inspection target data decomposition unit according to a sixth embodiment. FIG. 10 is a diagram illustrating a configuration example of a marking addition unit according to a sixth embodiment. FIG. 10 is a diagram illustrating a configuration example of an inspection target data decomposition unit according to a sixth embodiment. FIG. 10 is a diagram illustrating a configuration example of a marking addition unit according to a sixth embodiment. FIG. 10 is a diagram illustrating a configuration example of an inspection target data decomposition unit according to a sixth embodiment. FIG. 18 shows an overview of a communication system according to a seventh embodiment. FIG. 19 is a diagram showing an outline of a communication system according to an eighth embodiment. The figure which shows the hardware structural example of the terminal device which concerns on Embodiment 1-8, and an inspection server apparatus.

In the first to eighth embodiments, when a check is given to a file to be transmitted outside the organization using an HTTP POST or an email attachment, and the check is confirmed by a proxy server or a mail server, the check is correctly given. A configuration for preventing information leakage by malware by permitting transmission outside the organization after removing the seal will be described.
In other words, in the first to eighth embodiments, the user can be surely identified that the user is performing file transmission to a website on the Internet using HTTP POST, and the user can block the file transmission using the other HTTP POST. Block unintentional file transmission and prevent information leakage.
In this method, it is not necessary to manage a list that can be transmitted outside the organization, and countermeasures are taken against illegal HTTP POST by malware simulating this method.

Embodiment 1 FIG.
FIG. 9 shows a configuration example of the communication system according to the present embodiment and an outline of the operation.

In FIG. 9, a terminal device 5000 is a computer used by a user 5005.
The terminal device 5000 corresponds to an example of a communication device.
The terminal device 5000 is provided with, for example, a CPU (Central Processing Unit), a memory, a hard disk device, and a communication card as hardware.
Further, the terminal device 5000 includes, for example, a browser 5004 and a check processing unit 5002 as software.
A file 5001 is a file that the terminal device 5000 transmits to the Web server device 5012 using the browser 5004 by HTTP.
A check processing unit 5002 is a means for giving a check to the file 5001.
A file 5003 with a check is a file in which a check is given to the file 5001 by the check processing unit 5002.

The inspection server device 5009 cooperates with the proxy server device 5008 to inspect data in the HTTP POST data and inspect the contents to be HTTP POSTed.
The inspection server device 5009 corresponds to an example of a data verification device.

An outline of the operation will be described below with reference to FIG.
The following (1) to (5) correspond to (1) to (5) in FIG.

(1) The user 5005 gives a check to the file 5001 to be POSTed to the Web server apparatus 5012 using the check processing unit 5002 according to this embodiment, and generates a file 5003 with a check.
The file with check 5003 can be separated into the original file 5001, check data, and a user identifier.
The check data and the user identifier are information used to verify that the file 5001 is not data operated by malware.

(2) The user 5005 displays the Web page of the Web server device 5012 using the browser 5004, and transmits a file 5003 with a check from the terminal device 5000 instead of the file 5001 on the file transmission page.
At this time, the browser 5004 includes a file 5003 with a check mark in the HTTP body (message body, hereinafter referred to as an HTTP body), and this processing is a function provided in a general browser.
Note that the file 5003 with a check is transmitted as HTTP POST data 5006 from the terminal device 5000.
The HTTP POST data 5006 includes an HTTP header and an HTTP body.
Strictly speaking, the HTTP POST data 5006 includes a request line and a blank line in addition to the HTTP header and the HTTP body, but these are omitted because they are not directly related to the description of the present embodiment.

(3) The HTTP POST data 5006 including the file 5003 with the check mark is transmitted from the terminal device 5000 to the proxy server device 5008 via the LAN 5013, through the (network) switch 5007.
Note that the proxy server device 5008 is transmitted as a packet in which an IP header, a TCP header, and the like are added to the HTTP POST data 5006.

(4) The proxy server device 5008 transfers the received HTTP POST data 5006 including the file 5003 with a check to the inspection server device 5009 via a network or the like.
The proxy server device 5008 may use “internet content adaptation protocol” which is a protocol using an external function.
Note that the HTTP POST data 5006 including the file 5003 with a check may be transferred not only via the network but also between the proxy server device 5008 and the inspection server device 5009 via a physical medium (offline).

(5) The inspection server device 5009 receives the HTTP POST data 5006 including the file 5003 with a seal.
Also, the inspection server device 5009 verifies the marking of the extracted HTTP POST data 5006.
In other words, the inspection server device 5009 determines whether the HTTP POST data 5006 includes the check data and the user identifier. If the HTTP POST data 5006 includes the check data and the user identifier, the file 5001 is created by malware. Verifies that the data is not manipulated.
If the check data and user identifier exist and the check data and user identifier are correct (if the file 5001 is not data operated by malware), the inspection server device 5009 deletes the check data and user identifier from the file 5003 with the check. Then, HTTP POST data 5010 including the file 5001 is generated.
On the other hand, when the verification data and the user identifier are not included in the HTTP POST data 5006, or when the check data and the user identifier are not correct, the inspection server device 5009 outputs an error.

(6) When the check data and the user identifier are correct, the inspection server device 5009 transfers the HTTP POST data 5010 including the file 5001 to the proxy server device 5008 via a network or the like.
If the inspection server device 5009 outputs an error, it transfers this to the proxy server device 5008.

(7) The proxy server device 5008 transmits the HTTP POST data 5010 including the file 5001 received from the inspection server device 5009 to the Web server device 5012 via the Internet 5011.
When the proxy server device 5008 receives an error from the inspection server device 5009, it sends nothing to the Internet and sends an HTTP error message to the terminal device 5000 of the user 5005.

Next, details of the terminal device 5000 in FIG. 9 will be described with reference to FIGS. 1 and 2.
FIG. 1 shows an internal configuration example of the terminal device 5000, and FIG. 2 shows an operation example of the terminal device 5000.
In FIG. 1 and FIG. 2, the terminal device 1 and the check processing unit 100 are described.
Further, FIG. 1 shows only elements necessary for the description of the present embodiment, and elements other than those shown in FIG. 1 may be added to the terminal device 1.

  As shown in FIG. 1, the check processing unit 100 is roughly divided into a data input unit 101, a check generation unit 102, a check key storage unit 103, a check addition unit 105, and a check data output unit 106.

In the check processing unit 100, the data input unit 101 inputs the check target data 1201.
The check target data 1201 is, for example, the file 5001 in FIG.
The data input unit 101 outputs the input check target data 1201 as the check mark data 1101 (S101 in FIG. 2).
For example, the data input unit 101 performs a process of extracting an actual data portion from the file structure of the file 5001 and outputs it as test mark data 1101.
The test mark data 1101 corresponds to an example of verification target data.

The check mark generation unit 102 inputs the check mark data 1101 and also inputs a user identifier 1207 that is an identifier of the user 5005.
The user identifier 1207 may be input from a GUI or may be read from a setting file.
Next, the check mark generation unit 102 outputs a check key read command 1102 to the check key storage unit 103.
The verification key read command 1102 includes a user identifier 1207.

The check key storage unit 103 stores a check key 1103 in association with the user identifier 1207 inside.
The check key storage unit 103 takes out the check key 1103 corresponding to the user identifier 1207 included in the check key read command 1102, outputs the extracted check key 1103 to the check generation unit 102, and the check generation unit 102 receives the check key 1103. Is input (S102_1 in FIG. 2).
The verification key 1103 is a private key for private key encryption held by the user 5005 in FIG. 9, and only the user 5005 knows its value.

The check mark generation unit 102 generates check mark data 1105 for the check mark data 1101 using the check key 1103 (S102_2 in FIG. 2).
The procedure for generating the check data will be described with reference to the flowchart of FIG.

The check mark generation unit 102 inputs the check mark data 1101 to the one-way hash function h () (S201_sp1 in FIG. 3).
Next, the check generation unit 102 encrypts the output of the one-way hash function h () with a check key 1103 (private key).
This process is a signature process using general public key cryptography.
Then, the result of encryption is used as verification data 1105 (S201_sp2 in FIG. 3).

  The check generation unit 102 outputs the generated check data 1105 to the check addition unit 105 (S102_3 in FIG. 2).

The check adding unit 105 inputs the check mark data 1101, the check data 1105, and the user identifier 1207, concatenates them to generate the data 1106 with the check, and the generated data 1106 with the check to the check data output unit 106. This is output (S105 in FIG. 2).
The check data 1105 and the user identifier 1207 correspond to examples of verification information.

The check data output unit 106 outputs the input data 1106 with the check as data 1204 with the check.
The data 1204 with a seal is, for example, the file 5003 with a seal in FIG. 9 (S106 in FIG. 2).
The check data output unit 106 converts the data 1106 with the check into a file structure and outputs it.

The packet generator 107 receives the data 1204 with the seal from the seal data output unit 106, uses the data 1204 with the seal as an HTTP body, and adds an HTTP header to the HTTP body to generate HTTP POST data.
This HTTP POST data corresponds to an example of communication data.
Further, the packet generation unit 107 generates a packet by adding an IP header, a TCP header, and the like to the HTTP POST data.
The packet generation unit 107 is a function included in the browser 5004, for example.

The packet transmission unit 108 transmits the packet generated by the packet generation unit 107 to the LAN 5013.
The packet transmission unit 108 is also a function included in the browser 5004, for example.

Next, details of the inspection server device 5009 will be described with reference to FIGS.
FIG. 5 shows an example of the internal configuration of the inspection server device 5009, and FIG. 6 shows an operation example of the inspection server device 5009.
5 and 6, the inspection server device 3 is described.
FIG. 5 shows only elements necessary for the description of the present embodiment, and elements other than those shown in FIG. 5 may be added to the inspection server device 3.

In the inspection server device 3, the data input unit 301 inputs transmission target data 3201.
The transmission target data 3201 is a packet transmitted from the terminal device 1.
Since the transmission target data 3201 is input from the network, the transmission target data 3201 includes elements other than the HTTP POST data 5006 including the check-added file 5003 in FIG.
HTTP POST data 5006 including a file 5003 with a seal is included in the body part of the transmission target data 3201.
The part other than the body part is a header part and has nothing to do with the HTTP POST data 5006.
For this reason, the data input unit 301 interprets the transmission target data 3201 and extracts the body part from the transmission target data 3201 to perform processing for extracting the HTTP POST data 5006 including the file with the check mark.
This extracted data is set as transmission target data 3101.
That is, the data input unit 301 outputs the input transmission target data 3201 as the transmission target data 3101 (S301 in FIG. 6).

The transmission target data decomposition unit 302 receives the transmission target data 3101, decomposes it into non-inspection target data 3103 and inspection target data 3102, and outputs each of them (S302 in FIG. 6).
For example, when the HTTP POST data 5006 including the file 5003 with the check mark is the transmission target data 3101, the non-inspection target data 3103 corresponds to the HTTP header, and the inspection target data 3102 corresponds to the HTTP body.

The following is an example format of HTTP POST data. From the request line to the blank line, the HTTP header corresponds to the message body, and the message body corresponds to the HTTP body.
Note that an appropriate value is actually set for xxx.

Request line POST / cgi-bin / submit. xxx HTTP / 1.1
Request header field Accept: xxx
Accept-Language: ja
Accept-Encoding: xxx
Referer: http: // OOXXX. sample. ΔΔΔ / shinsei. html
User-Agent: xxx
Host: XXX. sample. △△△
General header field Pragma: xxx
Cookie: xxx
Entity header field Content-Type: xxx
Content-Length: xx
・ Empty line (CR (0x0d) + LF (0x0a) only line)
-Message body (contains data of the file to be posted)
xxx

The inspection object data decomposing unit 303 receives the inspection object data 3102, decomposes it into the check data 3104, the test mark data 3105, and the user identifier 3109 and outputs each of them (S 303 in FIG. 6).
The check data 3104 is the check data 1105 in FIG. 1, and the check data 3105 is the check data 1101 in FIG.
The user identifier 3109 is the user identifier 1207 in FIG.

The check verification unit 304 inputs the check data 3104, the check data 3105, and the user identifier 1207.
The verification verification unit 304 outputs a verification key read command 3106 to the verification key storage unit 305.
The verification key read command 3106 includes a user identifier 3109.
The verification key storage unit 305 extracts the verification key 3107 corresponding to the user identifier 3109, outputs the extracted verification key 3107 to the verification verification unit 304, and the verification verification unit 304 inputs the verification key 3107 (S304_1 in FIG. 6). .

The seal verification unit 304 verifies the seal data 3104 from the seal data 3104 and the seal data 3105 using the verification key 3107 (S304_2 in FIG. 6).
A verification procedure of the check data 3104 will be described with reference to the flowchart of FIG.

The check verification unit 304 inputs the check mark data 3105 to the one-way hash function h (), and sets the result as h1 (S304_vp1 in FIG. 7).
Further, the seal verification unit 304 decrypts the seal data 3104 with the verification key 3107 (the public key encryption public key of the user 5005 in FIG. 9), and sets the result as h2 (S304_vp2 in FIG. 7).
Next, the seal verification unit 304 compares the results of h1 and h2, and confirms whether they match (S304_vp3 in FIG. 7).
If they match, it is determined that the verification data 3104 is successfully verified (S304_vp4 in FIG. 7).
That is, it is determined that the test mark data 3105 is not transmitted by malware.
On the other hand, if h1 and h2 do not match, it is determined that the verification has failed (S304_vp5 in FIG. 7).
This process is a signature verification process using general public key cryptography.
In the encryption / decryption process, data is encrypted with the public key and decrypted with the private key. In the signature / verification process, the data is encrypted with the private key and decrypted with the public key.
Further, when the data to be signed is large, the signature / verification is performed not on the data to be signed itself but on the data reduced by the one-way hash function (the example shown in this embodiment corresponds).

It should be noted that the one-way hash function held by the check-mark generation unit 102 in the check-processing unit 100 and the public key encryption algorithm are the one-way hash function held by the check-verification unit 304 in the check server device 3 and the public one, respectively. Match the key encryption algorithm.
An algorithm used in advance by the check processing unit 100 and the inspection server device 3 may be agreed and implemented.
In addition, when a plurality of algorithms can be implemented, there is a method of including what algorithm is used in the signature format.
The check processing unit 100 includes the one-way hash function used for the signature and the identifier of the algorithm of the public key encryption in the signature format, and the inspection server device 3 uses the one-way hash function used for the signature from the signature format. Then, the identifier of the public key encryption algorithm is taken out and the algorithm used for verification is determined.
Such a method may use existing technology.

If the verification data 3104 is not empty and the verification is correct, the verification verification unit 304 outputs the verification data 3105 (S304_3 in FIG. 7).
The check verification unit 304 outputs an error notification 3203 when the check data 3104 is empty (the check data 3104 does not exist) or when the check data is not verified correctly.

The transmission data generation unit 306 inputs the inspection mark data 3105 and the non-inspection target data 3103, concatenates them, and outputs the corrected transmission data 3108 (S306 in FIG. 7).
The modified transmission data 3108 corresponds to the HTTP POST data 5010 including the file 5001 in FIG.
That is, the corrected transmission data 3108 is data obtained by excluding the verification data 3104 and the user identifier 3109 from the transmission target data 3101.

The data output unit 307 receives the corrected transmission data 3108 and outputs the corrected transmission data 3202 (S307 in FIG. 7).
The modified transmission data 3202 is output to a network, for example, and therefore needs to be network data (packet) including HTTP POST data 5010 including the file 5001 in the body portion.
The data output unit 307 generates network data, and includes the HTTP POST data 5010 including the file 5001 in the body part, thereby outputting the corrected transmission data 3202 as network data.

  In FIG. 5, the data input unit 301 corresponds to an example of a communication data receiving unit, the seal verification unit 304 corresponds to an example of a data verification unit, and the transmission data generation unit 306 and the data output unit 307 are communication data transfer units. It corresponds to the example.

An example of screen data presented to the user 5005 by the check processing unit 5002 in FIG. 9 (the check processing unit 100 in FIG. 1) is shown as a check processing screen 6001 in FIG.
In the check processing screen 6001, the user 5005 designates a file to be transmitted in the field of the transmission target file 6002.
In the example of FIG. 10, “C: ¥ work ¥ sample.csv” is designated.
Next, the user 5005 designates the file name for outputting the checked file in the column of the output path 6003 of the file with the check.
In the example of FIG. 10, “C: ¥ work ¥ sample.csv.sig” is designated.
Next, the user 5005 presses a check button 6004.
At this time, the check processing unit 5002 (the check processing unit 100) may display the authentication screen 6005 and allow the user 5005 to input a password.
As a result, “C: ¥ work ¥ sample.csv.sig”, which is a file to which “C: ¥ work ¥ sample.csv” (corresponding to the file 5001 in FIG. 9) is added, is output (FIG. 9). Equivalent to a file 5003 with a check mark).
In FIG. 1, the transmission target file 6002 corresponds to the transmission target file 1205, and the output path 6003 of the file with a check corresponds to the output path 1206 of the file with a check.

FIG. 11 shows the relationship between the file 5001 in FIG. 9 and the file 5003 with a check.
When a check is added to the file 7001 (file 5001 in FIG. 9), the check data (B & M9 ｀ @ / Q! ...) and the user are added to the file 7001 like the file 7002 with the check (file 5003 with the check in FIG. 9). Identifiers are concatenated.
Note that the format of FIG. 11 is an example, and other formats may be used depending on the algorithm of the check.

  Examples of operations of the verification key 1103 and the verification key 3107 in the present embodiment are as follows.

The user 5005 generates a public key encryption key pair (private key / public key), and stores the private key together with the user identifier 1207 in the check key storage unit 103 of the check processing unit 100.
Further, the administrator of the inspection server device 3 is requested to have the public key stored in the verification key storage unit 305 of the inspection server device 3 together with the user identifier 1207 of the user 5005.

Alternatively, the user 5005 generates a public key encryption key pair (private key / public key), and stores the private key together with the user identifier 1207 in the verification key storage unit 103 of the verification processing unit 100.
Furthermore, the user 5005 presents the public key and the user identifier 1207 to the certificate authority, and is issued as a public key certificate (including the user identifier).
Further, the user 5005 requests the administrator of the inspection server device 3 to store the public key certificate in the verification key storage unit 305 of the inspection server device 3.
In this case, the user identifier is included in the public key certificate.

  In S304_1 in FIG. 6, the verification key storage unit 305 may communicate with an external public key certificate repository and obtain an unpublished certificate corresponding to the user identifier 1207 from the repository.

In the present embodiment, a method based on public key cryptography is shown as a method for checking, but a method based on common key cryptography may be applied as follows.
Only the differences when applying the common key encryption are shown below.

First, only the differences in the operation of the check processing unit 100 will be described.
The verification key 1103 stored in the verification key storage unit 103 in FIG. 1 is a common key encryption common key shared by the inspection server device 3 with the user holding the verification processing unit 100.
Then, the check processing of the check generation unit 102 follows FIG.
First, the seal data 1101 and the seal key 1103 (common key) are connected (S201_skh1 in FIG. 4).
Next, the result of concatenating the check data 1101 and the check key 1103 (common key) is input to the one-way hash function h (), and the result is set as the check data 1105 (S201_skh2 in FIG. 4).

Next, only the differences in the operation of the inspection server device 3 will be described.
A verification key 3107 stored in the verification key storage unit 305 in FIG. 5 is a common key encryption common key shared between the inspection server apparatus 3 and the user holding the check processing unit 100.
The verification verification process of the verification verification unit 304 follows FIG.
First, the test mark data 3105 and the verification key 3107 (common key) are connected (S304_vkh1 in FIG. 8).
Next, the result of concatenating the test mark data 3105 and the verification key 3107 (common key) is input to the one-way hash function h () (the result is h1) (S304_vkh2 in FIG. 8).
Next, it is confirmed whether h1 and the check data 3104 match (S304_vkh3 in FIG. 8).
If they match, it is determined that the verification is successful (S304_vkh4 in FIG. 8).
If they do not match, it is determined that the verification has failed (S304_vkh5 in FIG. 8).

In addition, although an example of a seal using encryption has been shown, for example, a keyword that the seal processing unit 100 holds in a fixed manner may be used as the seal data 1105.
Only the differences between the operations of the inspection processing unit 100 and the inspection server device 3 are shown.
In this case, the check key storage unit 103 is not used in the check processing unit 100 (S102_1 in FIG. 2 is not performed).
Here, for example, a character string “abcdefghijklmn” is used as the check data 1105 (S102_2 in FIG. 2 is replaced with this processing).
This character string is also held fixed in advance on the inspection server device 3 side.
In the inspection server device 3, when “abcdefghijklmn” appears as the check data 3104, it is determined that the check is correct (replace S304_2 in FIG. 6 with this processing).
In this case, in the inspection server device 3, the verification key storage unit 305 is not used (S304_1 in FIG. 6 is not performed).

In this way, in this embodiment, the user gives a check to a file to be HTTP POSTed, and the inspection server device checks whether the data of the file with the check attached to the body portion of the HTTP data exists.
Since the malware normally HTTP-posts the file as it is, when the inspection server device inspects the file, there is no seal in the body part of the HTTP data, so an error notification is generated, and the inspection server device transfers to the proxy server device. The HTTP data that is about to be transferred is not transferred.
Therefore, malware cannot leak files to the Internet.

As described above, according to this embodiment, since malware cannot transmit a file to the Internet, there is an effect of preventing leakage of the file to the Internet by the malware.
Further, there is an effect that it is not necessary to manage a list of files permitted to be transmitted in the check processing unit or the inspection server device.

Embodiment 2. FIG.
In this embodiment, as a countermeasure against a case where malware with advanced functions steals a file on the terminal, activates the check processing unit, and performs HTTP POST as a file with a check, in the process at the time of check, USB ( A configuration in which an external device such as a Universal Serial Bus) token or a smart card is combined will be described.
In the following, only differences from the first embodiment will be described.
In the following, a method for checking is shown by an example using public key cryptography and a one-way hash function.

FIG. 12 shows a configuration example of the terminal device 1 according to the present embodiment.
In FIG. 12, compared to the configuration of FIG. 1, the verification key storage unit 103 is omitted, and an external device cooperation unit 104 serving as an interface with the external device 2 is provided instead.
The external device 2 is, for example, a USB token or a smart card.
The other elements are the same as those shown in FIG.

  Next, the marking process according to the present embodiment will be described with reference to FIG.

In the check processing unit 100 according to the present embodiment, the check generation unit 102 does not use the check key storage unit 103 but outputs the check mark data 1101 and the check command 1104 to the external device linkage unit 104 (FIG. 13). S102_es1).
The check instruction 1104 is an instruction that the check data 1101 can be encrypted using a one-way hash function h () and a public key encryption private key.
For example, although not shown, an identifier of how the external device 2 should perform a check (in this case, an electronic signature using public key cryptography and a one-way hash function), or a one-way hash function h () and public key encryption algorithm identifiers.
The check command 1104 also includes a user identifier.

  The external device linkage unit 104 converts the test mark data 1101 and the check command 1104 into a format that can exchange data with the external device 2, and outputs the data to the external device 2 as the test mark data 2201 and the check command 2202, respectively (see FIG. 13 S104_es1).

The external device 2 performs a check on the check mark data 2201 instead of the check processing in the check mark generation unit 102 of the first embodiment, generates the check data 2203, and outputs it to the external device link unit 104 (FIG. 13). S2_es1).
At the time of marking, it is necessary to search for a private key stored in the external device 2, but the external device 2 searches for a private key managed together with the user identifier.

  The external device cooperation unit 104 receives the check data 2203 from the external device 2, converts it into a format that can be interpreted by the check generation unit 102, and outputs it as the check data 1105 (S104_es2 in FIG. 13).

  The seal generation unit 102 receives the seal data 1105 from the external device cooperation unit 104 and outputs the input seal data 1105 to the seal addition unit 105 (this is a process corresponding to S102_3 in FIG. 2 and is indicated as S102_es2 in FIG. 13). ing).

The external device 2 is a smart card or a USB token that can process public key cryptography and a one-way hash function.
If the external device 2 is a USB token, the external device cooperation unit 104 is implemented as a software function that calls a USB function.
If the external device 2 is a smart card, a reader / writer is interposed between the external device cooperation unit 104 and the external device 2 (not shown).
Then, the external device cooperation unit is implemented as a software function for calling a reader / writer function.

When the external device 2 performs only public key encryption processing, the following processing is performed.
The test mark data 1101 output from the mark generation unit 102 to the external device cooperation unit 104 is set to a value obtained by applying the one-way hash function to the test mark data 1101 output from the data input unit 101. replace.
Since this value is output to the external device 2 as the inspected seal data 2201, the external device 2 performs only the encryption with the public key encryption private key on the inspected seal data 2201, and generates the inspected data 2203.
Further, the external device 2 outputs the check data 2203 to the external device cooperation unit 104.
In this case, the verification instruction 1104 is an instruction that the data to be checked 1101 can be encrypted by a public key encryption private key.

Except for the processing described above, the same processing as in the first embodiment is performed in the terminal device 1 and the inspection server device 3.
As shown in the first embodiment, the method of using the common key cryptography may be used for generating the seal.

In this embodiment, since a part of the generation process of the seal is processed by the external device, malware that cannot use the external device cannot attach the seal to the file. Therefore, even if HTTP POST is performed on the Web server device on the Internet, There is an effect that an error occurs in the inspection of the seal in the inspection server device and the file cannot be leaked.
For this reason, even if sophisticated malware attempts to misuse this method and leak a file, it requires an inspection by an external device and has an effect that cannot be exploited.

Embodiment 3 FIG.
In the second embodiment, the external device 2 is caused to process a part of the generation process of the seal.
In the present embodiment, a method is shown in which the external device 2 does not process a part of the generation process of the checkmark but performs the check mark generation process on the condition that the external apparatus exists.
Below, only the difference from Embodiment 2 is demonstrated about the process at the time of a check.

In the present embodiment, additional data to be input / output among the marking generation unit 102, the external device cooperation unit 104, and the external device 2 is as shown in FIG.
In FIG. 14, the illustration is omitted for the reason of drawing. However, as in FIG. 12, the check mark data 1101, the check instruction 1104, the check data 1105, the check mark data 2201, the check instruction 2202, and the check data 2203 are input. In addition to the output, the data shown in FIG. 14 is input / output.

FIG. 15 shows the process of generating a seal in the present embodiment.
Other operations in the check processing unit 100 are the same as those in the first embodiment.
Processing of the marking generation unit 102 in the present embodiment will be described using FIGS. 14 and 15.

  First, the sign generation unit 102 outputs an authentication command 1107 to the external device cooperation unit 104 before performing the check process (S102_a1 in FIG. 15).

When the authentication command 1107 is input, the external device cooperation unit 104 exchanges authentication information 2205 with the external device 2 and authenticates the external device 2 (S104_1 in FIG. 15).
For example, as an authentication method, it is checked whether or not the external device cooperation unit 104 can read the employee ID held by the external device 2.
In this case, the external device cooperation unit 104 outputs an instruction for reading the employee ID to the external device 2, and the external device 2 reads the employee ID stored therein and outputs it to the external device cooperation unit 104. .
Therefore, the employee ID read command and the employee ID correspond to the authentication information 2205.
In this example, the external device 2 stores the employee ID in a predetermined place inside, and can authenticate the external device 2 by being able to read and provide the employee ID to the external device cooperation unit 104. It is an example of authentication.

As another example, an example of exchanging challenge and response authentication information is shown.
In this case, when the random number C generated by the external device cooperation unit 104 is output to the external device 2, the external device 2 has a key (SK) previously shared between the external device cooperation unit 104 and the external device 2 with respect to C. ) And the function f.
This is expressed as R = f (C, SK).
The function f is implemented in advance by the external device cooperation unit 104 and the external device 2 as an algorithm.
The external device 2 outputs the result R to the external device cooperation unit 104.
The external device cooperation unit 104 calculates R ′ = f (C, SK) for C using the key SK held by the external device cooperation unit 104.
Then, R and R ′ input from the external device 2 are compared to check whether R ′ = R.
If R ′ = R, it is determined that the external device 2 shares the same key SK as the external device cooperation unit 104, and authentication is successful.
In this example, C and R correspond to the authentication information 2205.

  Next, the external device cooperation unit 104 outputs the result of authenticating the external device 2 to the seal generation unit 102 as an authentication result 1109 (S104_2 in FIG. 15).

The check mark generation unit 102 checks whether the authentication result 1109 is OK (authentication success of the external device 2) or NG (failure of authentication of the external device 2) (S102_a2 in FIG. 15).
In the case of OK, the marking generation unit 102 processes S102_1, S102_2, and S103_3 in FIG. 2 (Embodiment 1) (S102_123 in FIG. 15).
In the case of NG, the check generation unit 102 outputs an error notification 1208 to the outside of the check processing unit (S102_a3 in FIG. 15).
In the case of NG, the check processing unit 100 notifies the user that the check processing unit 100 has an error, for example, by displaying an error message on the GUI.
In this case, the data with a check is not output from the check processing unit 100.

When using the external device 2, authentication data 2204 for using the external device 2 may be input to the external device 2.
The method of inputting the authentication data 2204 to the external device 2 depends on the external device 2, but a dedicated GUI (application) for inputting from the terminal device 5000 (FIG. 9) to the external device 2 is separately prepared. There is.
Also, there is a method of displaying a GUI for inputting the authentication data 2204 in the check processing unit 100, allowing the user to input the authentication data 2204, and inputting to the external device 2 via the external device cooperation unit 104. Yes (broken line in FIG. 14).

In the present embodiment, since cooperation with an external device is required for the check processing, malware that cannot use the external device cannot attach a check to the file. Therefore, even if HTTP POST is performed on the Web server device on the Internet, the check is not performed. There is an effect that an error occurs in the inspection of the seal in the server device and the file cannot be leaked.
For this reason, even if sophisticated malware tries to exploit this method and leak a file, an external device is required and there is an effect that cannot be exploited.

Embodiment 4 FIG.
In the present embodiment, the marking generation unit 102 performs authentication using an image.
Only the difference between the first embodiment and the processing at the time of the check will be described.

The check generation unit 102 requests the user who uses the check processing unit 100 to authenticate with an image such as CAPTCHA before the check processing.
When the authentication by the image is successful, the marking process according to the first embodiment is performed.
The configuration of terminal device 1 according to the present embodiment is the same as the configuration shown in FIG. 1, FIG. 12, or FIG.

  Processing of the marking generation unit 102 according to the present embodiment will be described with reference to FIG.

The marking generation unit 102 stores “a pair of a distorted character string image and an actual character string displayed in the image” in a plurality of pairs in advance before the activation of the marking processing unit 100.
Then, at the start timing of the check processing unit 100, a pair of the plurality of pairs is selected at random.
Then, the check mark generation unit 102 displays the “distorted character string image” selected as the authentication data based on the image on the GUI (S102_ag1 in FIG. 16).
Here, the display of the distorted character string image is a request for authentication data to the user.
In addition to displaying a distorted character string image, this GUI also includes an interface for inputting a character string.

Next, the user visually determines the character string of the distorted image and inputs the character string to the GUI.
The input character string corresponds to the authentication data 1203 from the user shown in FIG. 14 (S102_ag2 in FIG. 16).

The check mark generation unit 102 compares the match between the input authentication data and the character string (stored inside) that is paired with the image of the distorted character string displayed on the GUI (S102_ag3 in FIG. 16). If yes (Yes), S102_1, S102_2, and S102_3 of FIG. 2 are processed (S102_123 of FIG. 16).
If they do not match (No), the check generation unit 102 outputs an error notification 1208 to the outside of the check processing unit 100 (S102_ag4 in FIG. 16).

  Since the malware may monitor and misuse the input character string from the GUI, the check mark generation unit 102 generates a distorted image pattern and a pair of character strings to be paired by the check mark generation unit 102 itself. Alternatively, a large amount may be held in advance and displayed randomly each time the check processing unit 100 is activated.

Alternatively, for example, in FIG. 17, the system administrator operates the image-based authentication data distribution server apparatus 4 and sets a plurality of pairs for character strings that are paired with image authentication data (eg, distorted image patterns). The image-based authentication data 1024 is generated and distributed to the inspection processing unit 100 through the network.
The communication unit 1022 in the check generation unit 102 (not shown in FIG. 17 omits other elements) of the check processing unit 100 receives the image authentication data 1024 and inputs it to the image authentication data update unit 1021. .
The image system authentication data update unit 1021 updates and stores the image system authentication data 1024 in the image system authentication data storage unit 1023.
Each time the check processing unit 100 is activated, the check generation unit 102 selects a character string paired with the authentication data based on the image from the image-based authentication data storage unit 1023 at random or in a predetermined order. Then, the authentication data based on the image may be displayed on the GUI as the authentication data request 1202 in FIG.
Alternatively, the image-based authentication data 1024 in this example may be input to the image-based authentication data update unit 1021 as a file instead of being taken into the check processing unit 100 via the network.

Further, the authentication method using the image may not be CAPTCHA, and may be an authentication method in which images of a plurality of different animals are displayed and the lion answers what number the image is.
In this case, the authentication data request 1202 is an image of a plurality of different animals, and the authentication data 1203 is “third image”.
The seal generation unit 102 confirms whether the authentication data 1203 is appropriate as an answer.

In this embodiment, since image authentication is essential for the check processing, malware that cannot pass image authentication cannot give a check to a file. Therefore, even if HTTP POST is performed on a Web server device on the Internet, There is an effect that the file cannot be leaked due to an error in the inspection of the seal.
For this reason, even if sophisticated malware tries to exploit this method and leak a file, an external device is required and there is an effect that cannot be exploited.

Embodiment 5 FIG.
In the present embodiment, a countermeasure is shown for when the malware intercepts a file with a check inside the PC and performs HTTP POST to the C & C server.
Below, only the difference from Embodiment 1 is demonstrated about the process at the time of a check.

The check generation unit 102 allows a user who uses the check processing unit 100 to input a destination resource URL (Uniform Resource Locator) before the check processing.
The transmission destination URL corresponds to an example of the destination address of the verification target data.
An example of a GUI display screen of the check processing unit 100 is shown in FIG.
In FIG. 18, the user inputs a transmission target file 1302 and an output path 1303 of a file with a check using a check processing screen 1301, and further inputs a transmission destination URL 1304.
At this time, an authentication screen 1306 may be displayed to allow the user to input a password.
As a result, a file with a check (data 1204 with a check in FIG. 1) is output.

The terminal device 1 according to the present embodiment has a configuration shown in FIG. 20, for example.
The check generation unit 102 generates a file with a check including the transmission destination URL in the check data 1105.
The check mark generation unit 102 inputs the destination URL 1208 and the check mark data 1101, combines the send destination URL 1208 and the check mark data 1101, and sets the check mark data with the URL as the data to be checked. Treat as.
That is, the test mark data 1101 processed in S102_2 in FIG. 2 is processed by replacing it with “test mark data with a URL obtained by combining the destination URL 1208 and the test mark data 1101”.
The check mark generation unit 102 generates check data 1105 for the check mark data with a URL in the same procedure as in the first embodiment, and the generated check data 1105 and the destination URL 1208 (not shown) are the check addition unit 105. Output to.
The seal adding unit 105 combines the seal data 1105, the transmission destination URL 1208 (not shown), the seal data 1101, and the user identifier 1207 into the data 1106 with the seal.

FIG. 19 illustrates an example of processing performed by the seal generation unit 102 and the seal addition unit 105.
The check mark generation unit 102 combines the transmission destination URL 1404 with the file 1401 (corresponding to the check mark data 1101) that is the transmission target to obtain the check mark data with URL 1405.
The result of generating a check for the URL-attached check mark data 1405 is the check data 1402.
The check adding unit 105 combines the user identifier 1403 and the check data 1402 with the URL check target data 1405 (the file 1401 and the transmission destination URL 1404) to obtain the check-added data 1406.
Note that here, the check data 1402 is generated for the check data with URL 1405 (file 1401 and destination URL 1404), but the check data 1402 is set for the file 1401 as in the first embodiment. You may make it produce | generate.

After that, the packet generation unit 107 in FIG. 20 inputs the data with verification 1406 from the verification data output unit 106, uses the data with verification 1406 as an HTTP body, adds an HTTP header to the HTTP body, and generates HTTP POST data.
Further, the packet generation unit 107 includes the destination host name in the HTTP header (usually a process included in the browser).
This HTTP POST data corresponds to an example of communication data.
Further, the packet generation unit 107 generates a packet by adding an IP header, a TCP header, and the like to the HTTP POST data.
Then, the packet transmission unit 108 transmits the packet generated by the packet generation unit 107.

  In the present embodiment, the check generation unit 102 corresponds to an example of a verification information generation unit and a destination address input unit, the check addition unit 105 corresponds to an example of a data combination unit, and the packet generation unit 107 generates communication data. The packet transmission unit 108 corresponds to an example of a communication data transmission unit.

Next, the inspection object data disassembling unit 303 of the inspection server device 3 in FIG. 5 obtains the inspection mark data 3105, and the content is the URL-inspected inspection mark data 1405 in FIG.
That is, it is as follows.
http: // OOXXX. sample. ΔΔΔ / cgi-bin / submit. xxx
0123456789abcdefghij

  Next, the check verification unit 304 in FIG. 5 performs the same processing as in the first embodiment.

In the present embodiment, the inspection object data decomposing unit 303 outputs the test mark data 3105 (the test mark data with URL 1405 in FIG. 19) not only to the check verification unit 304 but also to the transmission data generation unit 306.
The transmission data generation unit 306 takes out the URL shown first (transmission destination URL 1404 in FIG. 19) from the inputted test mark data 3105.
That is, the following is taken out.
http: // OOXXX. sample. ΔΔΔ / cgi-bin / submit. xxx

Next, the transmission data generation unit 306 inputs the non-inspection target data 3103, and obtains the destination host name from the HTTP header included therein.
Then, the transmission data generation unit 306 checks whether the host name matches the host name portion of the URL.
A format example of HTTP POST data is shown below (in practice, an appropriate value is set for xxx).

Request line POST / cgi-bin / submit. xxx HTTP / 1.1
Request header field Accept: xxx
Accept-Language: ja
Accept-Encoding: xxx
Referer: http: // OOXXX. sample. ΔΔΔ / shinsei. html
User-Agent: xxx
Host: XXX. sample. △△△ ← Destination host name / general header field Pragma: xxx
Cookie: xxx
Entity header field Content-Type: xxx
Content-Length: xx
・ Empty line (CR (0x0d) + LF (0x0a) only line)
-Message body (contains data of the file to be posted)
xxx

Here, the transmission data generation unit 306 obtains the host name specified in “Host:”, and if the host name is “XXX.sample.ΔΔΔ”, the test mark data 3105 (FIG. 19). The URL matches the host portion of “http: //◯◯◯.sample.ΔΔΔ/cgi-bin/submit.xxx”, which is the URL extracted from the URL-inspected seal data 1405).
If they do not match, the seal verification unit 304 outputs an error notification 3203.
In the present embodiment, the transmission data generation unit 306 together with the seal verification unit 304 corresponds to an example of the data verification unit.

Next, the transmission data generation unit 306 obtains data obtained by removing the URL from the test mark data 3105.
That is, the URL is deleted from the URL-inspected mark data 1405 in FIG.
・ Before URL deletion http: // XXX. sample. ΔΔΔ / cgi-bin / submit. xxx
0123456789abcdefghij
・ After URL deletion 0123456789abcdefghij

Next, the transmission data generation unit 306 generates the corrected transmission data 3108 from the non-inspection target data 3103 and the data from which the URL is removed.
That is, the data from which the URL is removed enters the body of the HTTP request.
This means that the content of the file 5001 in FIG. 9 that was originally transmitted enters the body of the HTTP request.
When the format example of the HTTP POST data is used, the format is as follows.
Request line POST / cgi-bin / submit. xxx HTTP / 1.1
Request header field Accept: xxx
Accept-Language: ja
Accept-Encoding: xxx
Referer: http: // OOXXX. sample. ΔΔΔ / shinsei. html
User-Agent: xxx
Host: XXX. sample. △△△
General header field Pragma: xxx
Cookie: xxx
Entity header field Content-Type: xxx
Content-Length: xx
・ Empty line (CR (0x0d) + LF (0x0a) only line)
-Message body (contains data of the file to be posted)
0123456789abcdefghij

  In this way, by including the URL of the Web server device that the user wants to transmit in the verification, even if the malware attempts to intercept the file with the verification and try to HTTP POST to the C & C server, the inspection server device will host the host name in the HTTP header. In this case, the malware cannot check HTTP POST of the file to the C & C server.

Embodiment 6 FIG.
In the present embodiment, a method is shown in which a file with a seal is encrypted and decrypted by an inspection server device to protect against malware eavesdropping.
As a countermeasure against eavesdropping on the network, there is a method of encrypting the connection to the proxy server device with a protocol such as Secure Sockets Layer. In this embodiment, a file with a check, which exists in the terminal device, Consider the case where malware intercepted above.
When the malware transmits the intercepted file with a check to the C & C server via the proxy server device, the check server device confirms that the file with the check is correct.
As a result, the file with a check is transmitted to the C & C server.
Therefore, even if malware intercepts a file with a check on the terminal device, a method is shown to prevent the terminal device from knowing what is written.
Below, only the difference from Embodiment 1 is demonstrated about the process at the time of a check.

In the processing of the seal adding unit 105 of the seal processing unit 100 in FIG. 1, data 1106 with a seal is generated from the seal data 1105, the data to be tested 1101, and the user identifier 1207. The signature adding unit 1106 outputs the data encrypted with the public key of the key encryption to the verification data output unit 106 instead of the data 1106 with the verification.
Referring to FIG. 21, the connecting unit 1051 of the check adding unit 105 connects the check data 1105, the check mark data 1101, and the user identifier 1207, and outputs the data 1053 with the check.
Next, the public key encryption unit 1052 inputs the data 1053 with the seal, encrypts the data 1053 with the seal using the public key 1054 of the inspection server device 3, and the data 1106 ′ with the seal (encrypted seal) Data).
This is input to the check data output unit 106 (FIG. 1) as data 1106 with a check.

In the inspection server device 3 of FIG. 5, the inspection target data decomposition unit 303 decrypts the inspection target data 3102 (encrypted with the public key of the inspection server device) with the private key of the public key encryption of the inspection server device 3. After that, it is decomposed into the check data 3104, the check data 3105, and the user identifier 3109 and output.
Referring to FIG. 22, the public key decryption unit 3031 in the inspection target data decomposing unit 303 decrypts the inspection target data 3102 (encrypted data with verification) with the private key 3033 of the inspection server device, and with verification. Data 3034 is output.
The disassembling unit 3032 decomposes the data 3034 with the check into check data 3104, check mark data 3105, and a user identifier 3109, and outputs them.

In the above example, an example of encryption by public key encryption has been shown, but the key processing unit 100 and the inspection server device 3 may share a common key encryption key in advance and encrypt / decrypt with these keys.
In this case, the operation of the seal processing unit 100 will be described with reference to FIG. Output.
Next, the common key encryption unit 1055 inputs the data 1053 with the seal, encrypts the data 1053 with the seal using the common key 1056 shared with the inspection server device 3, and data 1106 ′ with the seal 1 (encryption). Output as data with a check mark).
This is input to the check data output unit 106 (FIG. 1) as data 1106 with a check.

The operation of the inspection server device 3 will be described with reference to FIG. 24. The common key decryption unit 3035 in the inspection target data decomposing unit 303 shares the inspection target data 3102 (encrypted, data with verification) with the verification processing unit 100. The common key 3036 (same as the common key 1056) is decrypted, and the data 3034 with a check is output.
The disassembling unit 3032 decomposes the data 3034 with the check into the check data 3104 and the check mark data 3105 and outputs them.

In addition, the seal adding unit 105 of the seal processing unit 100 generates a temporary common key encryption key, encrypts the data 1106 with the seal with the temporary common key encryption key, and checks the temporary common key encryption key. The encrypted data is encrypted with the public key of the server device 3, connected to the data 1106 with a seal, and output to the seal data output unit 106.
The check data output unit 106 outputs the data with the check to which the encryption key is connected to the outside of the check processing unit 100 as the data 1204 with the check.

The operation of the seal adding unit 105 of the seal processing unit 100 will be described with reference to FIG. 25. The temporary common key generating unit 1054 of the check adding unit 105 generates a temporary common key 1056 and outputs it to the public key encryption unit 1052.
The public key encryption unit 1052 encrypts the temporary common key 1056 with the public key 1053 of the inspection server device 3, and outputs the encrypted common key 1057.
The first concatenating unit 1051 concatenates the check data 1105, the check target data 1101, and the user identifier 1207 and outputs the data 1058 with the check to the common key encryption unit 1055.
The common key encryption unit 1055 uses the temporary common key 1056 to encrypt the signed data 1058 with the common key encryption, and outputs the encrypted signed data 1059 to the second connecting unit 10510.
The second concatenating unit 10510 concatenates the encrypted common key 1057 and the data with encrypted verification 1059, and provides the data with verification (encrypted data with verification) and the encrypted common key 1106 ′. Output.
This is input to the check data output unit 106 (FIG. 1) as data 1106 with a check.

In the inspection server device 3 of FIG. 5, the inspection target data decomposition unit 303 encrypts the inspection target data 3102 ′ (data with a seal encrypted with the temporary common key encryption key with the public key of the inspection server device 3). First, the temporary common key encrypted with the public key of the inspection server device 3 is decrypted with the private key of the inspection server device 3, and the temporary common key is decrypted. obtain.
Next, the encrypted data with a seal is decrypted with the temporary common key.
Then, it is decomposed into the check data 3104, the check data 3105, and the user identifier 3109 and output.
The operation of the inspection object data decomposing unit 303 of the inspection server device 3 will be described with reference to FIG. 26. The first decomposing unit 3037 of the inspection object data decomposing unit 303 indicates that “inspection object data (encrypted data with a seal)” The encrypted common key 3102 ′ ”is decomposed into encrypted data 3039 with a seal and encrypted common key 3038.
Then, the public key decryption unit 3031 inputs the encrypted common key 3038, decrypts the encrypted common key 3038 with the public key encryption using the private key 3033 of the inspection server device 3, and uses the decrypted result as a result. A temporary common key 30310 is output to the common key decryption unit 3035.
The common key decryption unit 3035 receives the encrypted data 3039 with the seal, decrypts it with the common key encryption using the temporary common key 30310, and decrypts the data 3034 with the seal as a result of the decryption. Output to 3032.
The second decomposing unit 3032 decomposes the data 3034 with the check into the check data 3104, the check mark data 3105, and the user identifier 3109, and outputs them.

Further, in the first embodiment, the output path 6003 of the file with a check mark is specified on the check processing screen 6001 in FIG. 10, but only the folder path is specified in the output path, and the file name is the check processing screen 6001. May be given automatically, such as a random or time stamp with a check.
If the user specifies the output path 6003 of the file with a seal including the file name, the user tends to include the original extension and the original file name, and as a result, the malware may be able to guess the contents of the file. .
For example, in the case of the file name “Top Secret_Customer List 2012.zzz” (zzz is an extension, the same applies hereinafter), it can be inferred that the file contains the customer's personal information (malware uses keywords such as top secret, customer, etc.) You may be looking for a file that is included in the file name).
If the malware lists file names in the directory, it may get a file with such a name.
Therefore, the check processing screen 6001 displays the contents of the file with the check 5003 (FIG. 9) from the file name such as “P9 $ uq71hr.zzz.sig” or “201208011036.zzz.sig”. You may convert it to a file that cannot be guessed.
Further, the original extension may be removed as in “P9 $ uq71hr.sig, 201208011036.sig”.
Further, the extension may be completely removed as in “P9 $ uq71hr” or “201208011036” so that the file itself is unknown.

When the Web server apparatus 5012 in FIG. 9 receives a file name such as “P9 $ uq71hr.zzz.sig”, it may not be understood unless the file is opened.
In addition, in the case of “P9 $ uq71hr.sig” or “P9 $ uq71hr”, it is not known by which application it can be opened.
Processing that is performed when it is desired to know the original file name will be described, although it may be solved if the Web server device 5012 and the application to be opened are arranged in advance.
The case where the data with a seal is encrypted by public key encryption in the seal processing unit 100 of FIG. 1 will be described.
In FIG. 21, the linking unit 1051 of the seal addition unit 105 outputs a file with a seal that is input to the seal processing unit 100 (FIG. 1) in addition to the seal data 1105, the seal data 1101, and the user identifier 1207. A path 1206 (either a full path or only a file name that does not include a path, for example, “Top Secret_Customer List 2012.zzz”) (FIG. 1) is input, and the output path 1206 of the data with seal 1053 and the file with seal Are output to the public key encryption unit 1052.
As a result, the data with a seal 1106 ′ (encrypted data with a seal) includes the original file name (“confidential_customer list 2012.zzz”).
In addition, the name of the file with a check output from the check processing unit 100 is assumed to be a random name from which the original file name cannot be estimated, and is, for example, “P9 $ quq71hr”.

  When “P9 $ uq71hr”, which is a file 5003 with a seal, is POSTed by the browser 5004 in FIG. 9, “P9 $ uq71hr” is set as the file name in the HTTP header (for example, Content-Disposition).

Then, the decomposition unit 3302 of the inspection object data decomposition unit 303 in FIG. 22 in the inspection server device 3 outputs the output path 1206 of the file with the check in addition to the check data 3104, the check mark data 3105, and the user identifier 3109.
In the transmission data generation unit 306 (FIG. 1) of the inspection server device 3, the output path 1206 of the file with a check is set in the header of HTTP data (for example, Content-Disposition).
As a result, the file name information included in the corrected transmission data 3108 is the original file name “confidential_customer list 2012.zzz”, and the Web server device 5012 in FIG. 9 has the file name “confidential_customer list 2012.zzz”. Can be received as.

  In this way, by encrypting the data 1204 with a check output from the check processing unit, even if the malware intercepts the data 1204 with a check, it does not identify what file it is, so it leaks a necessary file. There is an effect to prevent that.

Embodiment 7 FIG.
In the present embodiment, an embodiment will be described in which malware prevents a file from being leaked outside the organization by an attached mail (attached file of an electronic mail).
Hereinafter, differences from the first embodiment will be described.

FIG. 27 is a configuration diagram in the present embodiment.
The difference from FIG. 9 is shown.
The user 5005 uses the mailer 5004 ′ ((2)), and by sending the file 5003 with a check with an attached mail, the mail 5006 ′ with the file 5003 with the check attached is sent to the LAN 5013 ((3)). It is received by the mail server device 5008 ′ via the switch 5007.
The mail server device 5008 ′ transfers the mail 5006 ′ with the file 5003 with the check mark attached to the inspection server device 5009.
The inspection server device 5009 inspects the seal in the mail 5006 ′ to which the file with the seal 5003 is attached, and when successful, removes the seal from the file with the seal 5300 ((5)), and the mail to which the file is attached. 5010 ′ is transferred to the mail server device 5008 ′ ((6)).
The mail server device 5008 ′ transmits a mail 5010 ′ with a file attached to the Internet 5011 ((7)) and receives it at the mail transmission destination 5012 ′.

The operation of the check processing unit 100 is the same as that in the first embodiment.
In the operation of the inspection server device 3 in FIG. 5, the transmission target data decomposition unit 302 outputs an attached file with a check as the inspection target data 3102.
In addition, the mail text and header part are output as non-inspection target data 3103.
In addition, the transmission data generation unit 306 concatenates the inspection mark data 3105 and the non-inspection target data 3103, so that a mail with a file to which no check data is attached as an attached file is output as the corrected transmission data 3108.

  In addition, as a countermeasure against the interception of a file with a check mark by malware, the method of the fifth embodiment can be applied. In this case, a destination mail address may be specified instead of the destination URL.

  In the present embodiment, the method of applying a check by the check processing unit 100 to the file to be transmitted to the Web server device and the method of verifying and removing the check in the inspection server device 3 are also applied to the attached e-mail. Has the effect of preventing files from being leaked outside the organization via attached emails.

Embodiment 8 FIG.
In the present embodiment, an embodiment for preventing malware from leaking data to a bulletin board of a blog site will be described.
Hereinafter, differences from the first embodiment will be described.

Differences from the first embodiment will be described with reference to FIG.
The user 5005 describes a document (post data 5015) to be posted on the blog site with the text editor 5013 and saves it in the file 5001.
Further, the check processing unit 5002 is used to generate a file 5003 with a check ((1)).
Further, the user 5005 opens the file 5003 with the seal with a text editor 5013, copies the content of the file with the seal (post data 5014 with the seal), and pastes it in the post field of the Web server device of the bulletin board using the browser 5004. Post ((2)).
As a result, HTTP POST data 5006 '' ((3)) including post data with a check mark is transmitted to the proxy server device 5008.
At this time, post data 5014 with a seal is included in the HTTP body.
When the proxy server device 5008 transfers the HTTP POST data 5006 ″ including post data with a check to the inspection server device 5009 ((4)), the inspection server device 5009 includes HTTP POST data 5006 including post data with a check. In '', verification of the post data with seal is verified.
If the verification is successful, the seal is removed from the post data with seal 5014, and the HTTP POST data 5010 ″ including the post data 5015 is transferred to the proxy server device 5008.
The proxy server device 5008 transmits HTTP POST data 5010 ″ including post data to the Web server device 5012 via the Internet 5011.

  In this embodiment, since Embodiment 1 is also applied to data posted to a blog site, there is an effect of preventing data leakage to the blog site by malware.

In the above first to eighth embodiments, the information leakage prevention system in which the following processing is performed has been described.
The terminal device uses a check processing unit to check a file to be posted to the Web site, and transmits the file to the proxy server device (HTTP data).
The proxy server device forwards the received HTTP data to the inspection server device, and the inspection server device regenerates HTTP data from which the verification portion has been deleted when there is a verification and the verification of the verification is successful, and the proxy server device Forward to.
The proxy POSTs the HTTP data from which the verification part is deleted to the Web site.
When there is no check and when verification fails, the inspection server device notifies the proxy of an error.

Further, in the first to eighth embodiments, it has been described that the information leakage prevention system applies the following as a means for checking.
Fixed string Digital signature using public key cryptography and one-way hash function Electronic signature using common key cryptography and one-way hash function

In the first to eighth embodiments,
The following information leakage prevention system including countermeasures against the abuse of this method by malware was described.
The verification data includes the transmission destination URL, and the inspection server apparatus confirms that the transmission is made to a valid Web site by including the host name indicated in the HTTP header information in the URL.
The file with a seal is encrypted so that only the inspection server device can decrypt it.
The check processing unit requires authentication of the external device.
The check processing unit requires encryption processing of the external device.
The check processing unit requires image authentication.

In the first to eighth embodiments,
An information leakage prevention system for preventing information leakage due to data transmission to a blog site and file transmission by an attached mail as well as HTTP POST of a file to a website by malware has been described.

As mentioned above, although embodiment of this invention was described, you may implement in combination of 2 or more among these embodiment.
Alternatively, one of these embodiments may be partially implemented.
Alternatively, two or more of these embodiments may be partially combined.
In addition, this invention is not limited to these embodiment, A various change is possible as needed.

In the above embodiment, the user operates the terminal device, adds a seal to the file to be transmitted, and transmits it to the website or attaches it to the e-mail. Server), and when the user transfers the file and destination to be sent to the check server, the check is given and the check is added to the proxy server (when sending to the website) or mail server (when sending as e-mail) The file may be transferred.
In addition, although the private key and common key stored in the verification key storage unit 103 are described as user-specific, a plurality of users may use a common private key or common key.
Further, in the above embodiment, the description has been given using an example in which malware illegally manipulates data. However, the above embodiment also applies to an unauthorized internal user who cannot give a checkmark. The mechanism described in (4) can be applied.
That is, the inspection server device can detect data that has been illegally operated by an unauthorized internal user who cannot give a seal.

In FIG. 29, the terminal device 1 and the inspection server device 3 include a CPU 911 (also referred to as a central processing unit, a central processing unit, a processing unit, an arithmetic unit, a microprocessor, a microcomputer, and a processor) that executes a program.
The CPU 911 is connected to, for example, a ROM (Read Only Memory) 913, a RAM (Random Access Memory) 914, a communication board 915, a display device 901, a keyboard 902, a mouse 903, and a magnetic disk device 920 via a bus 912. Control hardware devices.
Further, the CPU 911 may be connected to an FDD 904 (Flexible Disk Drive), a compact disk device 905 (CDD), a printer device 906, and a scanner device 907. Further, instead of the magnetic disk device 920, a storage device such as an SSD (Solid State Drive), an optical disk device, or a memory card (registered trademark) read / write device may be used.
The RAM 914 is an example of a volatile memory. The storage media of the ROM 913, the FDD 904, the CDD 905, and the magnetic disk device 920 are an example of a nonvolatile memory. These are examples of the storage device.
The “check key storage unit 103” and the “verification key storage unit 305” described in the first to eighth embodiments are realized by the RAM 914, the magnetic disk device 920, and the like.
A communication board 915, a keyboard 902, a mouse 903, a scanner device 907, and the like are examples of input devices.
The communication board 915, the display device 901, the printer device 906, and the like are examples of output devices.

  The communication board 915 is connected to a network as shown in FIG.

The magnetic disk device 920 stores an operating system 921 (OS), a window system 922, a program group 923, and a file group 924.
The programs in the program group 923 are executed by the CPU 911 using the operating system 921 and the window system 922.

The RAM 914 temporarily stores at least part of the operating system 921 program and application programs to be executed by the CPU 911.
The RAM 914 stores various data necessary for processing by the CPU 911.

The ROM 913 stores a BIOS (Basic Input Output System) program, and the magnetic disk device 920 stores a boot program.
When the terminal device 1 and the inspection server device 3 are activated, the BIOS program in the ROM 913 and the boot program in the magnetic disk device 920 are executed, and the operating system 921 is activated by the BIOS program and the boot program.

The program group 923 executes the function described as “˜part” in the description of the first to eighth embodiments (other than “verification key storage unit 103” and “verification key storage unit 305”). The program is stored.
The program is read and executed by the CPU 911.

In the file group 924, in the description of the first to eighth embodiments, “determination of”, “determination of”, “calculation of”, “calculation of”, “comparison of”, “verification of” "," Generate "," Evaluate "," Update "," Set up "," Register "," Select "," Concatenate "," Encrypt " , Information, data, signal values, and variable values indicating the results of the processing described as “decoding of”, “input of”, “output of”, etc. as files on a storage medium such as a disk or memory It is remembered.
The encryption key / decryption key, random number value, and parameter may be stored as a file in a storage medium such as a disk or memory.
The “˜file” and “˜database” are stored in a storage medium such as a disk or a memory.
Information, data, signal values, variable values, and parameters stored in a storage medium such as a disk or memory are read out to the main memory or cache memory by the CPU 911 via a read / write circuit.
The read information, data, signal value, variable value, and parameter are used for CPU operations such as extraction, search, reference, comparison, calculation, calculation, processing, editing, output, printing, and display.
Information, data, signal values, variable values, and parameters are stored in the main memory, registers, cache memory, and buffers during the CPU operations of extraction, search, reference, comparison, calculation, processing, editing, output, printing, and display. It is temporarily stored in a memory or the like.
The arrows in the flowcharts described in the first to eighth embodiments mainly indicate input / output of data and signals.
Data and signal values are recorded on a storage medium such as a memory of the RAM 914, a flexible disk of the FDD 904, a compact disk of the CDD 905, a magnetic disk of the magnetic disk device 920, other optical disks, a Blu-ray (registered trademark) disk, and a DVD.
Data and signals are transmitted online via a bus 912, signal lines, cables, or other transmission media.

In addition, what is described as “to part” in the description of the first to eighth embodiments may be “to circuit”, “to device”, “to device”, and “to step”, It may be “˜procedure” or “˜processing”.
Moreover, the process of the terminal device 1 and the test | inspection server apparatus 3 can be grasped | ascertained as a data processing method.
In addition, what is described as “to part” may be realized by firmware stored in the ROM 913.
Alternatively, only software, hardware such as an element, a device, a substrate, and wiring, a combination of software and hardware, or a combination of firmware may be used.
Firmware and software are stored as programs in a storage medium such as a magnetic disk, a flexible disk, an optical disk, a compact disk, a Blu-ray (registered trademark) disk, and a DVD.
The program is read by the CPU 911 and executed by the CPU 911.
That is, the program causes the computer to function as “to part” in the first to eighth embodiments. Alternatively, the computer executes the procedure and method of “to unit” in the first to eighth embodiments.

As described above, the terminal device 1 and the inspection server device 3 shown in the first to eighth embodiments are output devices such as a CPU as a processing device, a memory as a storage device, a magnetic disk, a keyboard as an input device, a mouse, a communication board, and the like. A computer including a display device, a communication board, and the like.
Then, as described above, the functions indicated as “˜units” are realized using these processing devices, storage devices, input devices, and output devices.

  DESCRIPTION OF SYMBOLS 1 Terminal device, 2 External apparatus, 3 Inspection server apparatus, 4 Image system authentication data delivery server apparatus, 100 Marking processing part, 101 Data input part, 102 Marking production | generation part, 103 Sealing key preservation | save part, 104 External apparatus cooperation part, 105 Check addition unit, 106 Check data output unit, 107 Packet generation unit, 108 Packet transmission unit, 301 Data input unit, 302 Transmission target data decomposition unit, 303 Inspection target data decomposition unit, 304 Check verification unit, 305 Verification key storage unit, 306 Transmission data generation unit, 307 Data output unit.

Claims (6)

Communication data that is classified into a header and a body, wherein the destination host name of the communication data is included in the header, and the verification target data to be verified receives the communication data included in the body And
Verifying whether or not the verification data used to verify that the verification target data is not data that has been illegally operated by at least one of malware and an unauthorized user is included in the body of the communication data ; It verifies whether or not the destination address of the verification target data specified by the user of the device that is the transmission source of the communication data is included in the body of the communication data, and the verification information is included in the body of the communication data The verification target data and the verification information are used to verify that the verification target data is not illegally manipulated data, and the destination address is included in the body of the communication data And comparing the destination host name in the header of the communication data with the destination address in the body, and the destination host indicated by the destination host name A data verifying unit to determine whether the destination host matches indicated by the serial destination address,
When the data verification unit determines that the verification target data is not illegally manipulated data, and further determines that the destination host indicated by the destination host name matches the destination host indicated by the destination address And a communication data transfer unit that excludes the verification information and the destination address from the body and transfers the communication data from which the verification information and the destination address are excluded . The data verification unit
The communication data is transferred to the communication data transfer unit at least one of when the verification information is not included in the communication data and when it is determined that the verification target data is illegally operated data The data verification apparatus according to claim 1, wherein an error is notified to a transmission source apparatus of the communication data without causing the communication data to be transmitted. The data verification unit
The communication in at least one of the case where the destination address is not included in the body of the communication data and the case where it is determined that the destination host indicated by the destination host name does not match the destination host indicated by the destination address without performing the communication data transferred to the data transfer unit, the data verification system according to claim 1, characterized in that notifies an error to the transmission source device of the communication data. The communication data receiving unit
Receiving communication data in which the content of the body is encrypted;
The data verification device further includes:
A decoding unit for decoding the content of the body of the communication data;
The data verification unit
After the content of the body of the communication data is decrypted by the decryption unit, it is verified whether the verification information is included in the body of the communication data, and the destination address is included in the body of the communication data. The data verification apparatus according to claim 1 , wherein the data verification apparatus verifies whether the data is present. The communication data receiving unit
The data verification apparatus according to claim 1, wherein communication data including HTTP (HyperText Transfer Protocol) data and e-mail data is received as the verification target data. Communication data that is classified into a header and a body, wherein the destination host name of the communication data is included in the header, and the verification target data to be verified receives the communication data included in the body Processing,
Verifying whether or not the verification data used to verify that the verification target data is not data that has been illegally operated by at least one of malware and an unauthorized user is included in the body of the communication data; It verifies whether or not the destination address of the verification target data specified by the user of the device that is the transmission source of the communication data is included in the body of the communication data, and the verification information is included in the body of the communication data The verification target data and the verification information are used to verify that the verification target data is not illegally manipulated data, and the destination address is included in the body of the communication data And comparing the destination host name in the header of the communication data with the destination address in the body, and the destination host indicated by the destination host name And determining data verification processing whether the destination host matches indicated by the serial destination address,
When it is determined by the data verification processing that the verification target data is not illegally manipulated data, and it is further determined that the destination host indicated by the destination host name matches the destination host indicated by the destination address A program for causing a computer to execute communication data transfer processing for excluding the verification information and the destination address from the body and transferring the communication data from which the verification information and the destination address are excluded.

Images