COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM

Abstract

To enhance security in communication.SOLUTION: A communication system (S) includes a first device (30) and a second device (20). A generation unit (101) generates multiple pieces of information based on a request received from the first device (30). The first device (30) transforms original data based on the multiple pieces of information and transmits the transformed data to the second device (20). The second device (20) inversely transforms the transformed data based on the multiple pieces of information to acquire the original data.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present disclosure relates to a communication system, a communication method, and a program. [Background technology]

[0002] Conventionally, in the field of communications, a technique for converting original data so that the contents of the original data are not known to a third party is known. For example, Patent Document 1 describes a technique for generating user parameters based on a user ID input by a user, and converting biometric data, which is an example of original data, based on the generated user parameters. For example, Patent Document 2 describes a technique for converting salt, which is an example of original data, by using a public key cryptosystem. For example, Patent Document 3 describes a technique called challenge and response, which is a type of public key cryptosystem. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 4966765 [Patent Document 2] Patent No. 6866803 [Patent Document 3] Republished Publication No. 2020-85141 Summary of the Invention [Problem to be solved by the invention]

[0004] However, in the technology of Patent Document 1, since user parameters are transmitted over a network, a malicious third party can easily obtain the user parameters. If a third party somehow obtains a user's biometric data, it becomes possible for the third party to spoof the user's identity using the illegally obtained user parameters and biometric data. Since the user parameters are generated based on a user ID that does not change in principle once issued, a third party can spoof the user's identity for a long period of time by using the user parameters once obtained.

[0005] The public key cryptosystems of Patent Documents 2-3 are cryptosystems that use a pair of a public key that is made public to a third party and a private key that is not made public to a third party. However, since a private key is information that does not change in principle, if a third party somehow obtains the private key, the third party can use the private key once obtained to commit fraud for a long period of time. The technologies of Patent Documents 1-3 make it possible to commit fraud for a long period of time, and therefore cannot sufficiently improve security in communications.

[0006] One objective of this disclosure is to increase security in communications. [Means for solving the problem]

[0007] A communication system according to one embodiment of the present disclosure is a communication system including a first device and a second device, and includes a generation unit that generates a plurality of pieces of information based on a request from the first device, the first device converts original data based on the plurality of pieces of information and transmits the converted data to the second device, and the second device inversely converts the converted data based on the plurality of pieces of information to obtain the original data. Effect of the Invention

[0008] According to the present disclosure, security in communications is increased. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 illustrates an example of an overall configuration of a communication system. [Diagram 2] FIG. 2 is a diagram showing an example of a flow of multi-factor authentication in the first embodiment. [Diagram 3] FIG. 2 is a functional block diagram illustrating an example of functions implemented in the communication system of the first embodiment. [Figure 4] FIG. 13 is a diagram illustrating an example of a salt database. [Diagram 5] FIG. 4 is a diagram illustrating an example of a user database. [Figure 6] FIG. 2 is a diagram illustrating an example of a process executed in the communication system of the first embodiment. [Figure 7] FIG. 2 is a diagram illustrating an example of a process executed in the communication system of the first embodiment. [Figure 8] FIG. 11 is a diagram illustrating an example of a flow of multi-factor authentication in the second embodiment. [Figure 9] FIG. 11 is a diagram illustrating an example of functional blocks realized in a communication system according to a second embodiment. [Figure 10] FIG. 13 is a diagram illustrating an example of an overall configuration of an authentication system according to a third embodiment. [Figure 11] FIG. 13 is a diagram illustrating an example of a flow of multi-factor authentication in the third embodiment. [Figure 12] FIG. 13 is a diagram illustrating an example of a functional block realized in an authentication system according to a third embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] [1. First embodiment] A first embodiment, which is an example of an embodiment of a communication system according to the present disclosure, will be described. In the first embodiment, a case where the communication system is applied to a scene where user authentication is performed will be described as an example, but the communication system can be applied to any scene. Examples of application to other scenes will be described in Modification 5 described later.

[0011] [1-1. Overall configuration of the communication system] Fig. 1 is a diagram showing an example of the overall configuration of a communication system. As shown in Fig. 1, the communication system S includes a salt server 10, an authentication server 20, and a user PC 30. The salt server 10, the authentication server 20, and the user PC 30 can be connected to a network N such as the Internet or a LAN. The communication system S only needs to include at least one computer, and is not limited to the example of Fig. 1.

[0012] The salt server 10 is a server computer. The control unit 11 includes at least one processor. The storage unit 12 includes a volatile memory such as a RAM and a non-volatile memory such as a hard disk. The communication unit 13 includes at least one of a communication interface for wired communication and a communication interface for wireless communication.

[0013] The salt server 10 is an example of a management device. Therefore, the description of the salt server 10 can be replaced with the description of the management device. The management device may be any device and is not limited to a server computer such as the salt server 10. For example, the management device may be a personal computer, a tablet terminal, or a smartphone.

[0014] The salt server 10 manages salts in cryptography. Salt is information for converting information to be converted. Salt is information that is input to a conversion function together with the information to be converted. The conversion is sometimes called encryption or hashing. The conversion is reversible. Information after conversion can be restored to the information before conversion by performing an inverse conversion. Managing salts means storing salts.

[0015] The salt itself may be a known salt. For example, the salt is a random value. The salt may be in any format, for example, numbers, letters, other symbols, or a combination of these. The salt server 10 may generate the salt, or the salt may be generated by a device other than the salt server 10.

[0016] The authentication server 20 is a server computer. The physical configurations of the control unit 21, the storage unit 22, and the communication unit 23 may be similar to those of the control unit 11, the storage unit 12, and the communication unit 13, respectively.

[0017] The authentication server 20 is an example of the second device. Therefore, the description of the authentication server 20 can be replaced with the description of the second device. The second device may be any device and is not limited to a server computer such as the authentication server 20. For example, the second device may be a personal computer, a tablet terminal, or a smartphone.

[0018] The user PC 30 is a personal computer of a user. The physical configurations of the control unit 31, the storage unit 32, and the communication unit 33 may be similar to those of the control unit 11, the storage unit 12, and the communication unit 13, respectively. The operation unit 34 is an input device such as a mouse, a keyboard, or a touch panel. The display unit 35 is a liquid crystal display or an organic EL display. The photographing unit 36 ​​includes at least one camera.

[0019] The user PC 30 is an example of the first device. Therefore, the description of the user PC 30 can be replaced with the description of the first device. The first device may be any device and is not limited to a personal computer such as the user PC 30. For example, the first device may be a tablet terminal, a smartphone, or a wearable terminal. For example, the first device may be another device such as a game machine, a vending machine, a POS terminal, or an ATM.

[0020] The programs stored in the storage units 12, 22, and 32 may be supplied via the network N. For example, the programs stored in the information storage medium may be supplied via at least one of a reading unit (e.g., an optical disk drive or a memory card slot) that reads a computer-readable information storage medium and an input / output unit (e.g., a USB port) that inputs and outputs data to and from an external device.

[0021] [1-2. Overview of the communication system in the first embodiment] For example, in the communication system S, multi-factor authentication is performed to verify the authenticity of a user. Multi-factor authentication is authentication that combines multiple factors. In the first embodiment, two-factor authentication that combines two factors is taken as an example, but multi-factor authentication that combines three or more factors may also be used. Various types of factors can be used, and may be, for example, a biometric factor, a possession factor, or a knowledge factor.

[0022] In multi-factor authentication, authentication data according to the factors is used. Various types of authentication data can be used. For example, in biometric authentication, biometric data such as a face photo, facial feature values, a fingerprint photo, fingerprint feature values, a vein scan image, or vein feature values ​​corresponds to the authentication data. In possession authentication, possession information such as a one-time password, information recorded on an IC card, or information recorded on a token corresponds to the authentication data. In knowledge authentication, knowledge information such as a user ID, password, PIN, or secret question corresponds to the authentication data.

[0023] In the first embodiment, a case where multi-factor authentication is performed to log in to an online service is taken as an example, but multi-factor authentication can be applied to any situation. For example, multi-factor authentication can be applied to other situations such as when applying for an online service, when making an electronic payment, or when an administrative procedure is performed online. Various services can be applied as the online service itself. For example, a financial service, a communication service, a payment service, an electronic commerce service, or an SNS may correspond to the online service.

[0024] For example, when a user registers to use an online service, a user ID and password for logging in to the online service are issued. The user accesses the website of the online service with the user PC 30 and enters the user ID and password. The authentication server 20 verifies the authenticity of the user based on the user ID and password entered by the user. Once the authenticity of the user is confirmed, the user can log in to the online service.

[0025] If the user ID and password are required to be input every time a user logs in, it is very troublesome. For this reason, it is conceivable to reduce the trouble of inputting a user ID by using multi-factor authentication that combines face authentication and password authentication. However, even in this case, the trouble of inputting a password occurs. If a user logs in using only face authentication without inputting anything to the operation unit 34, there is a possibility that erroneous authentication with another user with a similar face may occur. If the imaging unit 36 ​​includes a 3D sensor, face authentication can be performed with a certain degree of accuracy, but erroneous authentication may still occur. If the imaging unit 36 ​​does not include a 3D sensor, the probability of erroneous authentication increases. There is also a possibility that a third party who somehow obtains a user's face photo may impersonate the user.

[0026] Therefore, in the first embodiment, in order to ensure security and not generate an input from the operation unit 34, when the user logs in to the online service, the authentication server 20 issues a temporary user ID. Hereinafter, this temporary user ID is referred to as a TUID (Temporary User ID). The TUID is information capable of identifying the user. The TUID becomes invalid when a predetermined invalidation condition is satisfied. In the first embodiment, a case where the invalidation condition corresponds to the user logging in to the online service is taken as an example, but the invalidation condition may be any condition. For example, the invalidation condition may be the passage of a predetermined expiration date, the occurrence of a certain number of logins, or the user performing a predetermined operation.

[0027] The TUID issued by the authentication server 20 is recorded in the user PC 30. In the first embodiment, a case is described in which the TUID is recorded as a browser cookie, but the TUID may be recorded as information other than a cookie. The TUID may be displayed on the display unit 35, but in principle is not visible to the user. From the second login onwards, TUID authentication using the TUID is performed in addition to facial authentication. TUID authentication is a type of possession authentication, as TUID authentication is not successful unless the user PC 30 has the TUID recorded on it. It is believed that multi-factor authentication that combines facial authentication and TUID authentication can ensure a certain degree of security without requiring input from the operation unit 34.

[0028] However, if the same TUID is reused for a long period of time, there is a possibility that a valid TUID may be stolen by a malicious third party. For example, a cookie may be stolen by a third party through a replay attack, and the TUID contained in the cookie may also be stolen. If a third party somehow obtains not only the TUID but also a photo of the user's face, they may be able to spoof the user's identity. For this reason, it may be possible to invalidate the TUID after a certain period of time.

[0029] However, if the TUID becomes invalid immediately, users who do not log in frequently will need to enter their user ID and password every time, which reduces user convenience. Therefore, in the first embodiment, the TUID is converted using a salt to improve user convenience and prevent the TUID from being stolen by a third party. However, if the same salt is reused for a long period of time, there is a possibility that the salt itself may be stolen by a third party, so multiple salts are generated each time a user logs in.

[0030] Fig. 2 is a diagram showing an example of the flow of multi-factor authentication in the first embodiment. As shown in Fig. 2, when a user logs in to an online service, the user PC 30 transmits a salt request to the salt server 10 to obtain a salt. In the example of Fig. 2, a command such as createSaltPair() is included in the salt request. Since this command does not include conditions related to the salt, even if a malicious third party intercepts the salt request, they cannot identify the conditions under which the salt is generated.

[0031] When the salt server 10 receives a salt request, it generates a pair of salts, a first salt "6437" and a second salt "8414", and stores them in the salt database DB1. The salt pairs are not generated dynamically on the spot, but rather a large number of salts may be stored in advance in the salt database DB1, and the salt server 10 may obtain the salt pairs from the salt database DB1. The first salt and the second salt may be automatically deleted after a certain period of time. The salt server 10 transmits the first salt "6437" and the second salt "8414" to the user PC 30.

[0032] When the user PC 30 receives the first salt "6435" and the second salt "8414" from the salt server 10, it converts the TUID "312456" based on the second salt "8414" and a predetermined conversion function f. In the example of FIG. 2, the conversion function f is a function that adds the second salt "8414" to the TUID "312456". The converted TUID becomes "320870", which is the sum of these. The user PC 30 transmits an authentication request to the authentication server 20, which includes the user's face photo generated by the photographing unit 36, the first salt "6437", and the converted TUID "320870".

[0033] When the authentication server 20 receives the authentication request, it sends a salt request including the first salt "6437" to the salt server 10. This salt request is different from the salt request sent by the user PC 30. This salt request includes a command such as getSaltAndDelete(6437). This command is a command requesting the acquisition of the second salt "8414" and the deletion of the first salt "6437" and the second salt "8414".

[0034] When the salt server 10 receives the salt request, it refers to the salt database DB1, obtains the second salt "8414" associated with the first salt "6437" included in the salt request, and transmits it to the authentication server 20. The first salt "6437" is used as a query and index for searching for the second salt "8414". The salt server 10 deletes the first salt "6437" and the second salt "8414" from the salt database DB1.

[0035] When the authentication server 20 receives the second salt “8414” from the salt server 10, the authentication server 20 converts this salt “8414” into an inverse conversion function f -1 Based on this, the converted TUID “320870” received from the user PC is inversely converted. In the example shown in Figure 2, the inverse conversion function f -1 is a function that subtracts the second salt "8414" from the converted TUID "320870." The authentication server 20 obtains the TUID "312456" by inverse conversion.

[0036] When the authentication server 20 acquires the TUID "312456", it checks whether the TUID "312456" exists in the user database DB2. The user database DB2 stores authentication data that is the correct answer in multi-factor authentication. The process of checking whether the TUID "312456" exists corresponds to TUID authentication. If the TUID "312456" is not stored in the user database DB2, an error occurs at that point, and the user cannot log in.

[0037] When the authentication server 20 confirms that the TUID "312456" exists in the user database DB2, it acquires facial features stored in the user database DB2 in association with the TUID "312456". The authentication server 20 performs facial authentication based on the acquired facial features and facial features calculated from the face photo received from the user PC 30. If the facial authentication is successful, the authentication server 20 transmits an authentication result indicating that the multi-factor authentication was successful to the user PC 30. When the user PC 30 receives this authentication result, it is logged in to the online service.

[0038] In addition, if a malicious third party steals the converted TUID "320870" and the user's facial photo by a cross-site scripting (XSS) attack or the like after the user logs in, the third party may be able to spoof the user's identity. Therefore, when the user logs in, the authentication server 20 may issue a new TUID and store it in the user database DB2. That is, the authentication server 20 may update the TUID every time the user logs in. If the new TUID is "417632", the authentication server 20 may transmit an authentication result including the new TUID "417632" to the user PC 30. As a result, the TUID changes every time the user logs in, so that even if a third party performs a cross-site scripting (XSS) attack or the like as described above, the authentication cannot be successful, and spoofing can be prevented. The new TUID "417632" may be converted with the second salt "8414" already received from the salt server 10. In this case, the authentication server 20 stores a conversion function for converting the new TUID, and the user PC 30 stores an inverse conversion function f -1 In this reverse conversion, the second salt “8414” already received from the salt server 10 may be used.

[0039] As described above, the communication system S of the first embodiment converts the TUID and reverse-converts the converted TUID based on the first salt and the second salt. As a result, the TUID is not transmitted as is onto the network N, making it difficult for a third party to obtain the TUID. Furthermore, because the first salt and the second salt are dynamically generated in response to a request from the user PC 30, even if a third party somehow obtains the first salt and the second salt, there is a possibility that the first salt and the second salt may have expired at that time, thereby improving the security of communications. The communication system S of the first embodiment will be described in detail below.

[0040] [1-3. Functions realized by the communication system of the first embodiment] FIG. 3 is a functional block diagram showing an example of functions realized in the communication system S of the first embodiment.

[0041] [1-3-1. Functions realized in the Salt server] The data storage unit 100 is realized mainly by the storage unit 12. The salt generation unit 101, the reception unit 102, the transmission unit 103, the first deletion unit 104, and the second deletion unit 105 are realized mainly by the control unit 11.

[0042] [Data storage section] The data storage unit 100 stores data necessary for managing salts. For example, the data storage unit 100 stores a salt database DB1. If conversion information for converting a TUID and inverse conversion information for inversely converting the converted TUID are information called by a name other than salt, the salt server 10 may manage the conversion information and the inverse conversion information by using a database called by a name other than the salt database DB1.

[0043] 4 is a diagram showing an example of the salt database DB1. The salt database DB1 is a database in which a plurality of salts are stored in association with each other. For example, a pair of a first salt and a second salt is stored in the salt database DB1. Hereinafter, when the first salt and the second salt are not distinguished from each other, they are simply referred to as salts. When three or more salts are generated by the salt generation unit 101, the three or more salts are stored in the salt database DB1 in association with each other.

[0044] The multiple salts associated with each other in the salt database DB1 are an example of multiple pieces of information generated by the salt generation unit 101. Furthermore, the first salt is an example of first information, and the second salt is an example of second information. Therefore, a section describing multiple salts associated with each other can be read as multiple pieces of information. A section describing the first salt can be read as first information. A section describing the second salt can be read as second information.

[0045] Salt is an example of conversion information and an example of inverse conversion information. The word salt can be read as conversion information. The word salt can also be read as inverse conversion information. The conversion information is an encryption key in cryptography. The inverse conversion information is a decryption key in cryptography. In the first embodiment, the conversion information and the inverse conversion information are the same, so the conversion information and the inverse conversion information correspond to a common key in cryptography. The conversion information and the inverse conversion information may be called by names other than keys, and for example, a password used in encrypting a file may correspond to the conversion information and the inverse conversion information.

[0046] The conversion information and the inverse conversion information may be different from each other. For example, the conversion information may be a public key in cryptography, and the inverse conversion information may be a private key in cryptography. Conversely, the conversion information may be a private key in cryptography, and the inverse conversion information may be a public key in cryptography. When the conversion information and the inverse conversion information are different from each other, both the conversion information and the inverse conversion information are stored in the salt database DB1. Of these, the conversion information is sent to the user PC 30, and the inverse conversion information is sent to the authentication server 20.

[0047] Each piece of information generated by the salt generation unit 101 is information used in communication in the communication system S. This information may be the conversion information itself, or the inverse conversion information itself. Furthermore, this information may be information used to obtain the conversion information, or the inverse conversion information. This information may be information called by any name other than salt. For example, this information may be a key in cryptography, or a password set for a file. For example, this information may be called by other names such as a passcode or a password.

[0048] In the first embodiment, a case will be described in which the first information corresponds to identification information and the second information corresponds to conversion information and inverse conversion information, but the roles of the first information and the second information may be reversed. That is, the first information may correspond to conversion information and inverse conversion information, and the second information may be identification information. Identification information is information that can identify other information. Identification information can also be said to be information for searching other information. Identification information is used as an index when searching for other information.

[0049] The salt generation unit 101 may generate three or more pieces of information. Therefore, if the salt generation unit 101 generates n pieces of information (n is an integer equal to or greater than 3), there may be n pieces of information, namely, the first information to the n-th information. For example, if the conversion information and the inverse conversion information are different from each other, the salt generation unit 101 may generate three pieces of information, such as the first information, the second information, and the third information. In this case, the first information may correspond to the identification information, the second information may correspond to the conversion information, and the third information may correspond to the inverse conversion information. The roles of the first information to the third information may be interchanged among the identification information, the conversion information, and the inverse conversion information.

[0050] The data storage unit 100 can store any data other than the salt database DB1. For example, the data storage unit 100 may store an algorithm for generating salts. The data storage unit 100 may store data related to APIs for exchanging salts with the authentication server 20 and the user PC 30. In the first embodiment, salt requests of different formats are accepted from the authentication server 20 and the user PC 30, so a case will be described in which the API for the authentication server 20 and the API for the user PC 30 are different. However, the salt requests from the authentication server 20 and the user PC 30 may be unified into the same format, and a common API may be used for the authentication server 20 and the user PC 30.

[0051] [Salt generation section] The salt generation unit 101 generates a plurality of salts based on a request from the user PC 30. For example, the salt generation unit 101 generates a first salt and a second salt for conversion and inverse conversion as a plurality of salts. The salt generation unit 101 generates a plurality of salts based on a predetermined algorithm. For example, the salt generation unit 101 generates a plurality of salts so that the salts are different from each other and are random values. Various known methods can be used as a method for generating the random values. For example, a method using a timestamp at the time of salt generation may be used, or a method using data other than a timestamp may be used.

[0052] The salt generation unit 101 stores a plurality of generated salts in the salt database DB1. In the first embodiment, the salt generation unit 101 generates a first salt and a second salt. The salt generation unit 101 associates the first salt and the second salt with each other and stores them in the salt database DB1. Associating them with each other means making it possible to search for one from the other. In the first embodiment, an example will be given of a case in which the same salt is used for conversion of a TUID and for inverse conversion of the converted TUID.

[0053] [Receiver] The receiving unit 102 receives salt requests from each of the authentication server 20 and the user PC 30. The salt request is information in a predetermined format that is sent to request salt. In Fig. 2, a salt request including a command such as createSaltPair() or getSaltAndDelete (first salt) is given as an example, but the salt request may be any information indicating that salt has been requested, and is not limited to the example in Fig. 2.

[0054] In the first embodiment, a case will be described in which the salt request from the authentication server 20 and the salt request from the user PC 30 have different formats, but these formats may be the same. A salt request is an example of a request for conversion information and also an example of a request for inverse conversion information. Therefore, any description of a salt request can be read as a request for conversion information or a request for inverse conversion information. These requests can be called by any name other than a salt request.

[0055] [Transmitter] The transmitting unit 103 transmits a second salt equivalent to the inverse conversion information to the authentication server 20. For example, the transmitting unit 103 transmits the second salt equivalent to the inverse conversion information based on a salt request from the authentication server 20. The transmitting unit 103 transmits a first salt equivalent to the identification information and a second salt equivalent to the conversion information to the user PC 30. The transmitting unit 103 transmits the first salt and the second salt based on the salt request from the user PC 30.

[0056] 3, only one transmission unit 103 is shown, but the transmission of salt to the user PC 30 and the transmission of salt to the authentication server 20 can be regarded as separate functions. Therefore, the transmission unit 103 can be regarded as including a first transmission unit 103A that transmits salt to the user PC 30 when a salt request from the user PC 30 is accepted, and a second transmission unit 103B that transmits salt to the authentication server 20 when a salt request from the authentication server 20 is accepted. When the procedure for transmitting salt to the user PC 30 is different from the procedure for transmitting salt to the authentication server 20, the first transmission unit 103A may transmit salt to the user PC 30 according to the procedure for transmitting salt to the user PC 30. The second transmission unit 103B may transmit salt to the authentication server 20 according to the procedure for transmitting salt to the authentication server 20.

[0057] [First deleted part] The first deletion unit 104 deletes the multiple salts when a predetermined deletion time arrives after the multiple salts are generated. The deletion time is the time when the multiple salts should be deleted. The deletion time is a time a certain time after the generation time when the salts are generated. The length of the period from the generation time to the deletion time may be any length, and may be, for example, within 1 second, about 1 to 10 seconds, or more. Since the deleted salts become invalid, the deletion time can also be the time when the salts are invalidated.

[0058] Although omitted in Fig. 4, the salt database DB1 stores the deletion time of the first salt and the second salt. The first deletion unit 104 acquires the current date and time using a real-time clock or a GPS signal, etc., and determines whether the deletion time has arrived. The first deletion unit 104 deletes the first salt and the second salt for which it has been determined that the deletion time has arrived from the salt database DB1.

[0059] The salt database DB1 may store the generation time of the first salt and the second salt instead of the deletion time of the first salt and the second salt. In this case, the first deletion unit 104 may calculate the deletion time after a certain time from the generation time and determine whether the calculated deletion time has arrived. In addition, the length of the period from the generation time to the deletion time may not be common to all the first salts and the second salts, but may be set according to some condition such as a user or a time period.

[0060] [Second deleted part] The second deleting unit 105 deletes a plurality of salts based on a request from the authentication server 20. For example, the second deleting unit 105 deletes the first salt and the second salt when a salt request from the authentication server 20 is accepted and the second salt is transmitted to the authentication server 20. That is, even if it is before the time for deleting the first salt and the second salt arrives, the second deleting unit 105 deletes the first salt and the second salt from the salt database DB1 when the second salt is transmitted to the authentication server 20 and the first salt and the second salt are no longer necessary.

[0061] [1-3-2. Functions realized in the authentication server] The authentication server 20 inversely converts the converted TUID, which is an example of converted data, based on the multiple salts, to obtain the TUID, which is an example of original data. In the first embodiment, the authentication server 20 inversely converts the converted TUID to obtain the TUID, and executes authentication processing for the user based on the obtained TUID. The data storage unit 200 is realized mainly by the storage unit 22. A receiving unit 201, a salt requesting unit 202, a salt acquiring unit 203, an inverse converting unit 204, a processing executing unit 205, a TUID generating unit 206, and a transmitting unit 207 are also realized.

[0062] [Data storage section] The data storage unit 200 stores data necessary for communication with the user PC 30. In the first embodiment, since multi-factor authentication is performed in the communication system S, the data storage unit 200 stores data necessary for the multi-factor authentication. For example, the data storage unit 200 stores a user database DB2.

[0063] Fig. 5 is a diagram showing an example of the user database DB2. The user database DB2 is a database in which information about users is stored. For example, the user database DB2 stores a user ID, a password, a name, a TUID, a facial photo, and facial features. The information stored in the user database DB2 may be of any type and is not limited to the example of Fig. 5. For example, a session ID for maintaining a session with the user PC 30, a past login history by the user, or a usage history of online services by the user may be stored in the user database DB2.

[0064] A facial photograph is an example of biometric data (biometric information). A TUID is an example of authentication data (authentication information) different from biometric data. Therefore, any section describing a facial photograph can be read as biometric data. Any section describing a TUID can be read as authentication data different from biometric data. Any combination of biometric data and authentication data different from biometric data may be used. This combination is a combination of factors in multi-factor authentication.

[0065] Biometric data is data used in biometric authentication. The biometric data itself may be various data, for example, facial features may correspond to the biometric data. Information called a template into which facial features are converted may correspond to the biometric data. When biometric authentication other than face authentication is used, biometric data corresponding to the biometric authentication may be used. Examples of other biometric data are as described above. Authentication data different from the biometric data is information used in multi-factor authentication together with the biometric data. This authentication data is possession information or knowledge information. In the case of multi-factor authentication with three or more factors, there may be multiple pieces of authentication data different from the biometric data.

[0066] The data storage unit 200 can store any data other than the user database DB2. For example, the data storage unit 200 stores an inverse transformation function f -1 For example, the data store 200 may store an algorithm for generating a TUID.

[0067] [Receiver] The receiving unit 201 receives the first salt and the converted TUID from the user PC 30. The converted TUID is an example of converted data. Therefore, the parts describing the converted TUID can be read as converted data. The converted data is data obtained by converting the TUID, which is an example of original data. The original data is data that is the subject of conversion. The original data is data before conversion. The original data corresponds to plain text in cryptography. In the first embodiment, the original data is authentication data related to the user of the user PC 30. Since the original data is data before conversion, it is also called raw data.

[0068] In the first embodiment, the receiving unit 201 receives the converted TUID and a facial photograph from the user PC 30. Receiving the facial photograph means receiving image data of an image in which a face is photographed. The facial photograph may be a still image or an individual frame included in a moving image. In the first embodiment, a case in which the converted TUID and the facial photograph are included in an authentication request is taken as an example. For this reason, the receiving unit 201 receives the converted TUID and the facial photograph by receiving an authentication request from the user PC 30. The authentication request is a request for performing multi-factor authentication. The authentication request may be made by transmitting information in a predetermined format. The authentication request may include other information. For example, the authentication request may include information capable of identifying the user PC 30, such as the IP address of the user PC 30.

[0069] [Salt request section] The salt request unit 202 requests the remaining salts from the salt server 10 based on some of the multiple salts. The some salts are salts that the authentication server 20 has received from the user PC 30. The remaining salts are salts that the authentication server 20 has not received from the user PC 30. For example, the salt request unit 202 requests a second salt from the salt server 10 based on the first salt. The salt request unit 202 requests the second salt by transmitting a salt request including the first salt to the salt server 10. This salt request is a request for requesting a second salt associated with the first salt.

[0070] [Salt Acquisition Department] The salt acquisition unit 203 acquires the remaining salts based on some of the salts among the multiple salts. The some salts are salts used to acquire the remaining salts. The remaining salts are salts used as inverse conversion information. For example, the salt acquisition unit 203 acquires a second salt based on a first salt. The salt acquisition unit 203 is an example of an inverse conversion information acquisition unit. Therefore, the part explaining the salt acquisition unit 203 can be read as an inverse conversion information acquisition unit. The inverse conversion information acquisition unit acquires inverse conversion information, an example of which is salt. If the inverse conversion information is called by a name other than salt, the inverse conversion information acquisition unit may be called by a name corresponding to this name. For example, if the inverse conversion information is called a key or a password, the inverse conversion information acquisition unit acquires a key or a password.

[0071] In the first embodiment, since the salt server 10 manages the first salt and the second salt, the salt acquisition unit 203 acquires the second salt associated with the first salt from the salt server 10. The first salt and the second salt may be managed by the authentication server 20 itself. In this case, the data storage unit 200 stores the salt database DB1. Furthermore, in this case, the salt generation unit 101, the reception unit 102, the transmission unit 103, the first deletion unit 104, and the second deletion unit 105 described as being realized by the salt server 10 are realized by the authentication server 20.

[0072] [Inverse conversion section] The inverse conversion unit 204 inversely converts the converted TUID, which is an example of converted data, based on the remaining salt acquired by the salt acquisition unit 203, to acquire the original data and the TUID, which is an example of authentication data. For example, the inverse conversion unit 204 inversely converts the converted TUID, based on the second salt, to acquire the TUID. The inverse conversion unit 204 executes an inverse conversion corresponding to the conversion by the conversion unit 303. The inverse conversion is equivalent to decryption in cryptography. An inverse conversion function f -1 is stored in the data storage unit 200. The inverse conversion unit 204 converts the converted TUID into an inverse conversion function f -1In the example of Fig. 2, inverse conversion unit 204 subtracts the second salt from the converted TUID to perform inverse conversion on the converted TUID and obtain the TUID.

[0073] The inverse transformation itself is performed using various inverse transformation functions f -1 2 can be used, and is not limited to subtraction as in FIG. 2. For example, the inverse transformation may be performed by addition, multiplication, division, matrix transformation, other calculations, or a combination of these. In the example of FIG. 2, for the sake of simplicity, the transformation function f and the inverse transformation function f -1 Although the cases where x and y are simple addition and subtraction are shown, in reality, they are assumed to be somewhat complicated calculation formulas. Furthermore, the inverse transformation is not limited to decryption in cryptography, but may be decompression of a compressed file. If decompression corresponds to the inverse transformation, compression corresponds to the transformation. Compression corresponds to the transformation in the first embodiment, since some transformation is performed on a file. Decompression corresponds to the inverse transformation in the first embodiment, since it is a process of returning a compressed file to its original state.

[0074] [Processing execution section] The process execution unit 205 executes authentication processing for the user based on the authentication data acquired by the inverse conversion. In the first embodiment, multi-factor authentication is described as an example of the authentication processing, but the authentication processing may be one-factor authentication. For example, face authentication may not be used and only authentication of the TUID may be executed. The process execution unit 205 may execute processing according to the scene in which the communication system S is applied, and the processing executed by the process execution unit 205 is not limited to authentication processing. Processing in the case where the communication system S is applied to other scenes will be described in a modified example described later. The process execution unit 205 may execute a predetermined processing based on the original data acquired by the inverse conversion unit 204.

[0075] For example, the process execution unit 205 executes multi-factor authentication based on the TUID inversely converted by the inverse conversion unit 204 and the facial photograph received by the receiving unit 201. As described above, various types of multi-factor authentication are available. In the first embodiment, the process execution unit 205 refers to the user database DB2 and acquires facial features associated with the TUID inversely converted by the inverse conversion unit 204. This facial feature is authentication data that is the correct answer in multi-factor authentication. Of the facial features stored in the user database DB2, only the facial feature associated with the TUID inversely converted by the inverse conversion unit 204 is compared. Other facial features are not compared.

[0076] The processing execution unit 205 calculates facial features based on the facial photograph received by the receiving unit 201. Various calculation methods can be used for the facial feature calculation method itself. For example, the facial feature may be calculated by a calculation method using a contrast filter or principal component analysis. The facial feature may be expressed in any format such as a multidimensional vector, an array, or a single numerical value. The facial recognition may be of a type that does not compare facial features with each other, but inputs two facial photographs into a machine learning model to determine whether they are similar or not.

[0077] The process execution unit 205 judges whether the facial feature amount acquired from the user database DB2 is similar to the facial feature amount calculated from the face photograph received by the receiving unit 201. For example, when the facial feature amount is expressed as a multidimensional vector, the facial feature amount being less than a threshold distance in the vector space corresponds to the feature amount being similar. When the facial feature amounts are similar to each other, the process execution unit 205 judges that the multi-factor authentication has been successful. When the facial feature amounts are not similar to each other, the process execution unit 205 judges that the multi-factor authentication has failed.

[0078] [TUID generator] The TUID generation unit 206 generates a TUID based on a predetermined algorithm. If no TUID exists in the user PC 30, the TUID generation unit 206 generates a new TUID to be recorded in the user PC 30. If a TUID exists in the user PC 30, the TUID generation unit 206 generates a TUID (updated TUID) to be written to the user PC 30 in place of the existing TUID.

[0079] For example, the TUID generation unit 206 generates a TUID so that the TUID is a random value. The method of generating the random value itself can use various known methods. For example, the method may use a timestamp when the TUID is generated, or a method may use data other than a timestamp. The TUID generation unit 206 stores the generated TUID in the user database DB2.

[0080] The TUID generation unit 206 may generate a TUID so that it does not overlap with the TUID of another user. The TUID generation unit 206 may allow the TUID to overlap with the TUID of another user whose face is dissimilar, but may generate a TUID so that it does not overlap with the TUID of another user whose face is similar. The TUID generation unit 206 may generate a TUID if multi-factor authentication is successful. That is, the TUID generation unit 206 may generate a TUID every time the user logs in to an online service. If it is the first login, the TUID generation unit 206 generates a TUID if authentication of the user ID and password is successful.

[0081] The timing at which the TUID is generated may be any timing and is not limited to the example of the first embodiment. For example, if the TUID is not invalidated after just one login but the same TUID is valid a predetermined number of times (two or more), the TUID generation unit 206 may generate a TUID each time the predetermined number of logins occur. For example, if an expiration date is set for the TUID, the TUID generation unit 206 may generate a TUID when the user logs in as the expiration date approaches.

[0082] [Transmitter] The transmission unit 207 transmits the authentication result of the multi-factor authentication to the user PC 30. The authentication result is information in a predetermined format indicating whether the multi-factor authentication has been successful or not. For example, the authentication result indicates whether login has been permitted or not. In the first embodiment, a new TUID is generated at the time of login, and therefore the authentication result includes the new TUID.

[0083] If the multi-factor authentication is successful, execution of a predetermined process is permitted. In the first embodiment, logging in to an online service is described as an example of this process, but this process may be permitted on the condition that the multi-factor authentication is successful. This process may be determined according to the situation in which the communication system S is applied. For example, when the communication system S is applied to a financial service, execution of a transfer may correspond to the predetermined process. For example, when the communication system S is applied to a payment service, execution of a payment may correspond to the predetermined process. For example, when the communication system S is applied to an electronic commerce service, purchasing a product may correspond to the predetermined process. The predetermined process may be any other process.

[0084] [1-3-3. Functions realized on user PC] User PC 30 converts the TUID, which is an example of original data, based on the multiple salts, and transmits the converted TUID, which is an example of converted data, to authentication server 20. Data storage unit 300 is realized mainly by storage unit 32. Salt request unit 301, salt acquisition unit 302, conversion unit 303, transmission unit 304, and reception unit 305 are realized mainly by control unit 31.

[0085] [Data storage section] The data storage unit 300 stores data necessary for multi-factor authentication. For example, the data storage unit 300 stores the TUID and the conversion function f. When the photographing unit 36 ​​is not used to generate a facial photograph of the user, the data storage unit 300 may store image data of the facial photograph of the user. For example, when an application for an online service is prepared, the data storage unit 300 may store the application.

[0086] [Salt request section] The salt request unit 301 requests a plurality of salts from the salt server 10. For example, the salt request unit 301 requests a first salt and a second salt from the salt server 10. The salt request unit 301 requests salt by transmitting a salt request to the salt server 10. In the first embodiment, the salt request unit 301 transmits a salt request to the salt server 10 that does not include information on the acquisition rule of the first salt and the second salt. For example, when the first salt and the second salt generated based on a timestamp are acquired, the acquisition rule is the timestamp. The salt request does not include information on the timestamp, and therefore does not include information on the acquisition rule.

[0087] The salt request may include a rule for obtaining the first salt and the second salt. For example, the salt request may include information that serves as a seed for generating the first salt and the second salt.

[0088] In the first embodiment, the salt request unit 301 transmits a salt request to the salt server 10 when a face photograph is generated by the photographing unit 36. The salt request unit 301 may transmit the salt request at any timing, and is not limited to the timing when a face photograph is generated. For example, the salt request unit 301 may transmit the salt request when an application for an online service is started, when a user performs an operation to log in, or when an access is made to a website of the online service.

[0089] [Salt Acquisition Department] The salt acquisition unit 302 acquires a plurality of salts. For example, the salt acquisition unit 302 acquires a first salt and a second salt. The salt acquisition unit 302 acquires a first salt and a second salt that are associated with each other in the salt database DB1. The salt acquisition unit 302 is an example of a conversion information acquisition unit. Therefore, the part explaining the salt acquisition unit 302 can be read as a conversion information acquisition unit. The conversion information acquisition unit acquires conversion information, an example of which is salt. If the conversion information is called by a name other than salt, the conversion information acquisition unit may be called by a name corresponding to this name. For example, if the conversion information is called a key or a password, the conversion information acquisition unit acquires a key or a password.

[0090] [Conversion section] The conversion unit 303 converts the original data and the TUID, which is an example of authentication data, based on a part of the multiple salts. For example, the conversion unit 303 converts the TUID based on the second salt to generate a converted TUID. The conversion is encryption in cryptography. The conversion may be any change made to the TUID. For example, inputting the TUID into some function, changing a part of the TUID, changing the entire TUID, adding some information to the TUID, or deleting a part of the TUID corresponds to the conversion. The inverse conversion may be a process in the opposite direction (a process of restoring the TUID to its original state). As described above, the compression of a file may correspond to the conversion, and the decompression of a file may correspond to the inverse conversion. In this case, the compression or decompression is performed using the second salt as a password.

[0091] The conversion function f for the conversion is assumed to be stored in the data storage unit 300. The conversion unit 303 converts the pre-conversion TUID with the conversion function f based on the salt, which is an example of conversion information. In the example of Fig. 2, the conversion unit 303 converts the pre-conversion TUID by adding the second salt to the pre-conversion TUID, and obtains the converted TUID. The conversion itself can use various conversion functions and is not limited to addition as shown in Fig. 2. For example, the conversion may be performed by subtraction, multiplication, division, matrix conversion, other calculations, or a combination of these.

[0092] [Transmitter] The transmitting unit 304 transmits some of the multiple salts and the converted TUID to the authentication server 20. The transmitting unit 304 transmits the first salt and the converted TUID to the authentication server 20. For example, the transmitting unit 304 transmits the first salt, the converted TUID, and a facial photo to the authentication server 20. In the first embodiment, a case where the first salt, the converted TUID, and a facial photo are included in the authentication request is exemplified. For this reason, a case where the transmitting unit 304 transmits an authentication request including the first salt, the converted TUID, and a facial photo to the authentication server 20 will be described, but the transmitting unit 304 does not need to transmit the first salt, the converted TUID, and the facial photo together in one data. The transmitting unit 304 may transmit the first salt, the converted TUID, and the facial photo separately. Note that the facial photo may also be converted based on the salt or another encryption key instead of being transmitted as it is. The facial feature amount may be calculated on the user PC 30 side, and the calculated facial feature amount may be transmitted as biometric data.

[0093] [Receiver] The receiving unit 305 receives the authentication result from the authentication server 20. If the authentication result indicates success, the user logs in to the online service. That is, the execution of the predetermined process described above is permitted. If the authentication result includes a new TUID, the receiving unit 305 records the TUID included in the authentication result in the data storage unit 300. The old TUID that had been recorded up to that point is discarded from the data storage unit 300.

[0094] [1-4. Processing Executed in the Communication System of the First Embodiment] Figures 6 and 7 are diagrams showing an example of processing executed in the communication system S of the first embodiment. The processing in Figures 6 and 7 is executed by the control units 11, 21, and 31 executing programs stored in the storage units 12, 22, and 32, respectively. It is assumed that a user ID and a password have already been issued to a user before the processing in Figures 6 and 7 is executed.

[0095] 6, the user PC 30 starts an application for an online service and determines whether or not there is a TUID in the storage unit 32 (S1). If it is determined that there is no TUID (S1; N), the user PC 30 accepts input of a user ID and password by the user based on a detection signal from the operation unit 34 (S2). A login process for logging in to the online service is executed between the authentication server 20 and the user PC 30 (S3). In S3, the validity of the user ID and password is confirmed based on the user database DB2. If the login is successful, the authentication server 20 issues a new TUID (S4) and transmits an authentication result including the new TUID to the user PC 30 (S5).

[0096] When the user PC 30 receives the authentication result (S6), it records the TUID included in the authentication result in the storage unit 32 (S7), and this process ends. In S7, the TUID may be recorded as part of a cookie. Thereafter, the user PC 30 executes a process for allowing the user to use the online service. When the user performs an operation to log out of the online service, a logout process for logging out of the online service is executed between the authentication server 20 and the user PC 30.

[0097] If it is determined in S1 that the TUID is present (S1; Y), the user PC 30 takes a picture of the user's face using the photographing unit 36 ​​to generate a facial photograph (S8). The user PC 30 transmits a salt request to the salt server 10 (S9). Upon receiving the salt request (S10), the salt server 10 generates a first salt and a second salt, stores them in the salt database DB1, and transmits the first salt and the second salt to the user PC 30 (S11). Upon receiving the first salt and the second salt from the salt server 10 (S12), the user PC 30 converts the TUID stored in the storage unit 32 based on the second salt (S13).

[0098] 7, the user PC 30 transmits an authentication request including the first salt received in S12, the TUID after conversion in S13, and the facial photograph generated in S8 to the authentication server 20 (S14). Upon receiving the authentication request (S15), the authentication server 20 transmits a salt request including the first salt to the salt server 10 (S16). Upon receiving the salt request (S17), the salt server 10 transmits a second salt associated with the first salt to the authentication server 20 based on the salt database DB1 (S18).

[0099] When the authentication server 20 receives the second salt from the salt server 10 (S19), it inversely converts the converted TUID included in the authentication request received in S15 based on the second salt (S20). The authentication server 20 executes multi-factor authentication based on the TUID inversely converted in S20 and the facial photograph included in the authentication request received in S15 (S21). In S21, the authentication server 20 acquires facial features associated with the TUID inversely converted in S20 based on the user database DB2. The authentication server 20 calculates the facial features based on the facial photograph received in S15. The authentication server 20 determines whether the similarity of the acquired facial features is equal to or greater than a threshold. If the TUID exists in the user database DB2 and the similarity of the facial features is equal to or greater than a threshold, the multi-factor authentication is successful.

[0100] The authentication server 20 determines whether the multi-factor authentication is successful (S22). If the multi-factor authentication is unsuccessful (S22; N), this process ends. In this case, the user may be requested to input a user ID and password. If the multi-factor authentication is successful (S22; Y), the user is permitted to log in to the online service, and the process proceeds to S4. The TUID of the user PC 30 is updated by the processes from S4 onward.

[0101] According to the communication system S of the first embodiment, the user PC 30 converts the TUID based on multiple salts and transmits the converted TUID to the authentication server 20. The authentication server 20 inversely converts the converted TUID based on multiple salts to obtain the TUID. As a result, the converted TUID is transmitted onto the network, making it difficult for a third party to obtain the TUID, thereby improving communication security. Even if a malicious third party steals a salt request from the authentication server 20 to the salt server 10, it is difficult for the first salt alone to understand the mechanism of the conversion, thereby further improving communication security. Furthermore, since the first salt and the second salt are generated based on the salt request from the user PC 30 to the salt server 10, even if a third party steals the first salt and the second salt in some way, it is highly likely that the first salt and the second salt are invalid at that time, and fraud by the third party can be prevented.

[0102] Furthermore, the user PC 30 transmits to the authentication server 20 the first salt and the TUID after conversion based on the second salt. The authentication server 20 acquires the second salt based on the first salt, and then acquires the TUID by inversely converting the converted TUID based on the acquired second salt. This improves the security of communications by using a pair of two salts. By using the second salt as both the conversion information and the inverse conversion information, security can be ensured with fewer salts. This simplifies the process for improving the security of communications, and reduces the processing load on the entire communications system S.

[0103] Furthermore, the salt server 10 generates a first salt and a second salt based on a salt request from the user PC 30. The salt server 10 transmits a second salt to the authentication server 20 based on a salt request from the authentication server 20. This eliminates the need for the authentication server 20 to manage the first salt and the second salt, and therefore the processing load in communication can be distributed. In other words, processing can be distributed between the salt server 10 and the authentication server 20. This allows the processing load on the authentication server 20 to be reduced.

[0104] In addition, the user PC 30 transmits a salt request that does not include information regarding the acquisition rules for the first salt and the second salt to the salt server 10. This makes it difficult for a malicious third party to decipher the mechanism for converting the TUID, even if the salt request is stolen. For example, even if the first salt and the second salt corresponding to the timestamp are acquired, the acquisition rules cannot be ascertained from the salt request alone, which further enhances security in communication.

[0105] In addition, the salt server 10 deletes multiple salts when a predetermined deletion time comes after multiple salts are generated. This allows unnecessary salts to be deleted from the salt database DB1, and the leakage of salts can be reliably prevented, thereby further improving communication security. It is also possible to reduce memory consumption of the salt database DB1.

[0106] In addition, the salt server 10 deletes multiple salts based on a request from the authentication server 20. This allows unnecessary salts to be deleted from the salt database DB1, and the leakage of salts can be reliably prevented, thereby further improving communication security. It is also possible to reduce memory consumption of the salt database DB1.

[0107] Furthermore, the authentication server 20 obtains a TUID by inversely converting the converted TUID, executes authentication processing for the user based on the obtained TUID, and generates a new TUID if the authentication processing is successful. This improves security during authentication. For example, since the TUID changes every time a user logs in, even if a third party attempts the above-mentioned cross-site scripting attack, the authentication cannot be successful, and therefore spoofing can be prevented.

[0108] [2. Second embodiment] In the first embodiment, a case has been described in which security in communication is enhanced by devising a method for acquiring a salt. The method for enhancing security in communication is not limited to the example of the first embodiment. In the second embodiment, the conversion function f is used differently depending on the first salt to enhance security in communication. In the second and third embodiments below, explanations of the same points as in the first embodiment will be omitted.

[0109] FIG. 8 is a diagram showing an example of the flow of multi-factor authentication in the second embodiment. In the second embodiment, the general flow may be similar to that of the first embodiment. In the example of FIG. 8, the method of acquiring the first salt and the second salt is similar to that of the first embodiment. The user PC 30 acquires the first salt "6437" and the second salt "8414" from the salt server 10 in the same manner as in the example of FIG. 2 of the first embodiment.

[0110] In the second embodiment, the user PC 30 uses different conversion functions f based on the last digit of the first salt "6437". For example, the user PC 30 stores conversion functions f0 to f9 corresponding to the last digits "0" to "9", respectively. Hereinafter, when the conversion functions f0 to f9 are not distinguished, they are simply referred to as conversion functions f. The calculation methods indicated by the individual conversion functions f are different from one another. For this reason, even if the salt is the same, if the conversion functions f are different, the TUID value after conversion will also be different.

[0111] In the example of Fig. 8, a conversion function f7 corresponding to the last digit "7" of the first salt "6437" is selected. This conversion function f7 is assumed to be the same as the conversion function f described in Fig. 2 of the first embodiment. The processing of the user PC 30 after the conversion function f7 is selected is the same as in the first embodiment. When the authentication server 20 receives the first salt "6437" and the converted TUID "320870", it acquires the first salt "6437" from the salt server 10 in the same manner as in the first embodiment.

[0112] In the second embodiment, the authentication server 20 calculates the inverse conversion function f based on the last digit "7" of the first salt "6437". -1 For example, the authentication server 20 uses the inverse conversion functions f -1 0~f -1 9 is stored. From now on, the inverse transformation function f -1 0~f -1 When 9 is not distinguished, simply use the inverse transformation function f -1 Each inverse transformation function f -1 Therefore, even if the second salt is the same, the inverse transformation function f -1 If the TUID is different, the TUID value after inverse conversion will also be different.

[0113] In the example in Figure 8, the inverse conversion function f -1 7 is selected. This inverse transformation function f -1 7 is the inverse transformation function f -1 The inverse transformation function f -1 The flow of multi-factor authentication including the processing of the authentication server 20 after 7 is selected is the same as in the first embodiment.

[0114] Fig. 9 is a diagram showing an example of functional blocks realized in the communication system S of the second embodiment. As shown in Fig. 9, in the second embodiment, an inverse conversion function selection unit 208 and a conversion function selection unit 306 are realized. The inverse conversion function selection unit 208 is realized mainly by the control unit 21. The conversion function selection unit 306 is realized mainly by the control unit 31. In the second embodiment, the first salt is not only identification information for acquiring the second salt, but also information for selecting a conversion method and an inverse conversion method for the TUID.

[0115] The conversion function selection unit 306 selects one of a plurality of conversion functions f based on the first salt. The conversion function f is an example of a conversion method. Therefore, the part explaining the conversion function f can be read as the conversion method. The conversion method is a method of converting a TUID. The conversion method is not limited to the conversion function f as long as it defines how to convert the TUID. For example, the conversion method may be a calculation formula not called a function, or an encryption algorithm. For another example, the conversion method may be a file compression algorithm.

[0116] The conversion function selection unit 306 may select one of the multiple conversion functions f based on a predetermined selection method related to the first salt. This selection method is a selection method for the conversion function f. This selection method is a method in which the first salt is a condition. When the value of the first salt changes, the selected conversion function f may also change. For example, the conversion function selection unit 306 selects one of the multiple conversion functions f based on a part of the first salt. The conversion function selection unit 306 may select the conversion function f based on the entire first salt.

[0117] In the second embodiment, a case where the value of the last digit of the first salt is used will be described as an example of a selection method. The conversion function selection unit 306 selects a conversion function f according to the last digit of the first salt. It is assumed that the relationship between the last digit of the first salt and the conversion function f is defined in advance in the data storage unit 300. The conversion function selection unit 306 selects a conversion function f corresponding to the last digit of the first salt. In the second embodiment, the numbers "0" to "9" that the last digit of the first salt can take correspond to the numbers included in the conversion functions "f0" to "f9".

[0118] In the second embodiment, the conversion function selection unit 306 selects one of the multiple conversion functions f based on the first salt, without requesting another device to select the conversion function f. The other device is a device other than the user PC 30. For example, the other device is the salt server 10, the authentication server 20, or another server computer. After the first salt is acquired, the conversion function selection unit 306 completes the selection of the conversion function f only through processing within the user PC 30. In a third embodiment described later, unlike the second embodiment, the selection of the conversion function f occurs by another device.

[0119] The conversion unit 303 generates a converted TUID based on the conversion function f selected by the conversion function selection unit 306. This embodiment differs from the first embodiment in that the conversion function f selected by the conversion function selection unit 306 is used, but other points are the same.

[0120] The inverse transformation function selection unit 208 selects a plurality of inverse transformation functions f -1 Select one of the inverse transformation functions f -1 is an example of an inverse transformation method. Therefore, the inverse transformation function f -1 The inverse transformation method is a method for inversely transforming a transformed TUID. The inverse transformation method can be defined as a method for inversely transforming a transformed TUID. -1However, the inverse transformation method is not limited to the above. For example, the inverse transformation method may be a calculation formula not called a function, or a decryption algorithm. As another example, the inverse transformation method may be a file decompression algorithm.

[0121] The inverse transformation function selection unit 208 selects a plurality of inverse transformation functions f based on a predetermined selection method for the first salt. -1 This selection method is based on the inverse transformation function f -1 This selection method is based on the first salt. When the value of the first salt changes, the inverse transformation function f -1 For example, the inverse transformation function selection unit 208 may select a plurality of inverse transformation functions f based on a part of the first salt. -1 The inverse transformation function selection unit 208 selects one of the inverse transformation functions f -1 may be selected.

[0122] In the second embodiment, the inverse transformation function f -1 As an example of a method for selecting the inverse conversion function f, the case where the last digit of the first salt is used will be described. The inverse conversion function selection unit 208 selects an inverse conversion function f according to the last digit of the first salt. -1 The last digit of the first salt and the inverse transformation function f -1 The relationship between the first salt and the second salt is defined in advance in the data storage unit 200. The inverse transformation function selection unit 208 selects an inverse transformation function f -1 For example, the inverse transformation function selection unit 208 selects an inverse transformation function f corresponding to the transformation function f selected by the transformation function selection unit 306. -1 Then, the inverse transformation function f -1 Select .

[0123] In the second embodiment, the inverse transformation function selection unit 208 selects an inverse transformation function f -1 Based on the first salt, multiple inverse transformation functions f -1 After the first salt is acquired, the inverse conversion function selection unit 208 selects one of the inverse conversion functions f-1 In the third embodiment described later, unlike the second embodiment, the inverse transformation function f -1 A selection occurs.

[0124] The inverse transformation unit 204 selects the inverse transformation function f -1 The TUID is acquired based on the inverse transformation function f selected by the inverse transformation function selection unit 208. -1 This embodiment differs from the first and second embodiments in that it uses the same circuit diagram, but is otherwise similar to the first and second embodiments.

[0125] According to the communication system S of the second embodiment, the user PC 30 selects one of the multiple conversion functions f based on the first salt. The authentication server 20 selects one of the multiple inverse conversion functions f based on the first salt. -1 In this way, the conversion function f changes dynamically, making it difficult for a third party to understand the conversion mechanism, and the security of the communication is improved. Even if a malicious third party steals the salt request, it is difficult for the first salt to understand the conversion mechanism, and the security of the communication is improved.

[0126] Furthermore, the user PC 30 selects one of the multiple conversion functions f based on the first salt without requesting the other device to select the conversion function f. The authentication server 20 can also request the other device to select the inverse conversion function f -1 Based on the first salt, multiple inverse transformation functions f -1 This selects one of the following functions: -1 Since no request is made to other devices to select the desired one, the processing during communication can be simplified. The time required to complete multi-factor authentication can also be shortened.

[0127] The user PC 30 selects one of the multiple conversion functions f based on a part of the first salt. The authentication server 20 selects one of the multiple inverse conversion functions f based on a part of the first salt. -1This allows us to select one of the transformation function f and the inverse transformation function f instead of using the first salt only to obtain the second salt. -1 Since the first salt can be used to select the transformation function f and the inverse transformation function f, the first salt can be used more effectively. -1 Since there is no need to prepare any other information other than the first salt in order to select -1 This simplifies the method of selecting

[0128] [3. Third embodiment] In the second embodiment, the authentication server 20 and the user PC 30 each use an inverse transformation function f -1 We have explained the case where the conversion function f is selected, but the inverse conversion function f -1 and the transformation function f may be selected by a third party server.

[0129] FIG. 10 is a diagram showing an example of the overall configuration of an authentication system S in the third embodiment. As shown in FIG. 10, the authentication system S in the third embodiment includes a selection server 40. The selection server 40 is a server computer. The physical configurations of the control unit 41, the memory unit 42, and the communication unit 43 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively. The selection server 40 is an example of a selection device. Therefore, the description of the selection server 40 can be replaced with the selection device.

[0130] The selection device selects a transformation function f and an inverse transformation function f -1 The selection device may be any device and is not limited to a server computer such as the selection server 40. For example, the selection device may be a personal computer, a tablet terminal, or a smartphone. For example, the selection device may be another device such as a game machine, a vending machine, a POS terminal, or an ATM.

[0131] FIG. 11 is a diagram showing an example of the flow of multi-factor authentication in the third embodiment. In the third embodiment, the general flow may be similar to that of the second embodiment. The flow up to the point where the user PC 30 obtains the first salt and the second salt is similar to that of the second embodiment. However, in FIG. 11, the first salt is set to "6430".

[0132] In the third embodiment, the user PC 30 transmits the first salt "6430" to the selection server 40. The selection server 40 stores a function database DB3. The function database DB3 contains the last digit of the first salt, a conversion function f, and an inverse conversion function f -1 In the example in Figure 11, the inverse transformation function f -1 Since the function database DB3 only shows the conversion function f, the function database also contains the conversion function f and the inverse conversion function f -1 Both of the above may be stored. The associations in the function database DB3 are updated at a predetermined timing. For example, the selection server 40 periodically updates the associations in the function database DB3 randomly.

[0133] The selection server 40 selects a conversion function f based on the last digit "0" of the first salt "6430" received from the user PC 30. The selection server 40 selects the conversion function f, but the method of selecting the conversion function f itself may be the same as that of the second embodiment. The selection server 40 transmits the selection result "f7" of the conversion function f to the user PC 30. When the user PC 30 receives the selection result "f7" of the conversion function f, it converts the TUID "312456". This conversion itself may be the same as that of the second embodiment. The subsequent flow is the same as that of the second embodiment until the authentication server 20 acquires the second salt "8414" from the salt server 10.

[0134] The authentication server 20 transmits the first salt "6430" to the selection server 40. Based on the last digit "0" of the first salt "6430" received from the authentication server 20, the selection server 40 calculates the inverse conversion function f -1 Select the inverse transformation function f-1 The selection server 40 is the entity that selects the inverse transformation function f -1 The selection method itself may be the same as that in the second embodiment. The selection server 40 selects the inverse transformation function f -1 Selection result of "f -1 7". The authentication server 20 transmits the inverse transformation function f -1 When the selection result of "320870" is received, the converted TUID "320870" is inversely converted. This inverse conversion itself may be the same as in the second embodiment. The subsequent flow of multi-factor authentication is the same as in the second embodiment.

[0135] Fig. 12 is a diagram showing an example of functional blocks realized in the authentication system S of the third embodiment. As shown in Fig. 12, in the third embodiment, an inverse conversion function request unit 209, a conversion function request unit 307, a data storage unit 400, a conversion function selection unit 401, an inverse conversion function selection unit 402, and an update unit 403 are realized. The inverse conversion function request unit 209 is realized mainly by the control unit 21. The conversion function request unit 307 is realized mainly by the control unit 31. The data storage unit 400 is realized mainly by the storage unit 42. The conversion function selection unit 401, the inverse conversion function selection unit 402, and the update unit 403 are realized mainly by the control unit 41.

[0136] The conversion function request unit 307 requests the selection server 40 to select a conversion function f based on the first salt. Hereinafter, this request is referred to as a conversion function selection request. The conversion function selection request may be made in a predetermined format. The conversion function selection request may include information that is a criterion for the selection server 40 to select the conversion function f, or may include only a command to select the conversion function f. In the third embodiment, a case will be described in which the conversion function selection request includes the first salt, but the conversion function selection request may include only the last digit of the first salt.

[0137] The inverse transformation function request unit 209 requests the selection server 40 to send an inverse transformation function f -1Hereinafter, this request is called an inverse transformation function selection request. The inverse transformation function selection request may be made in a predetermined format. The inverse transformation function selection request is made when the selection server 40 selects the inverse transformation function f -1 , and the inverse transformation function f -1 In the third embodiment, the inverse transformation function selection request includes the first salt, but the inverse transformation function selection request may include only the last digit of the first salt.

[0138] The conversion function selection unit 401 selects one of the multiple conversion functions f based on a conversion function selection request from the user PC 30. In the third embodiment, as in the second embodiment, a case will be described in which this selection method is the last digit of the first salt, but the selection method may be any other method. For example, it may be the first digit of the first salt, or the value of the second salt. The conversion function selection unit 401 transmits information that can identify the conversion function f selected by the selection server 40 as the selection result.

[0139] The inverse conversion function selection unit 402 selects a plurality of inverse conversion functions f based on an inverse conversion function selection request from the authentication server 20. -1 In the third embodiment, as in the second embodiment, a case will be described in which this selection method is the last digit of the first salt, but the selection method may be any other method. For example, it may be the first digit of the first salt, or the value of the second salt. The inverse conversion function selection unit 402 selects one of the inverse conversion functions f selected by the selection server 40. -1 The user is then sent information that can identify the user as the selection result.

[0140] The conversion function selection unit 306 selects a conversion function f based on the selection result by the selection server 40. This embodiment differs from the first and second embodiments in that the conversion function f selected by the selection server 40 is used, but is similar in other respects.

[0141] The inverse transformation function selection unit 208 selects an inverse transformation function f based on the selection result by the selection server 40.-1 The inverse transformation function f selected by the selection server 40 is selected. -1 This embodiment differs from the first and second embodiments in that it uses the same circuit diagram, but is otherwise similar to the first and second embodiments.

[0142] The update unit 403 updates the selection conditions for the first salt, the multiple conversion functions f and the multiple inverse conversion functions f -1 and updates the associations between each of the items in the function database DB3. In the third embodiment, since these associations are stored in the function database DB3, the update unit 403 updates the function database DB3. When a predetermined update condition is satisfied, the update unit 403 updates the associations in the function database DB3.

[0143] The update condition is a condition for updating the association in the function database DB3. The update condition may be any condition, for example, a time condition or a condition related to the conversion function f and the inverse conversion function f -1 The update condition may be a condition related to the number of selections of the association. For example, the administrator performing a predetermined operation may correspond to the update condition. In the third embodiment, a case will be described in which the update condition is a time condition, and the update unit 403 updates the association when a predetermined update time arrives. The update time may be any time point, and may be, for example, a predetermined time of day, or a time point set within a week or a month.

[0144] The update unit 403 may update the function database DB3 so that the association is different from the association before the update. For example, the update unit 403 may update the function database DB3 by using the last digit of the first salt, the conversion function f, and the inverse conversion function f -1 The association is updated so that the combination of and is shuffled. After the association is updated by the update unit 403, the conversion function selection unit 401 selects a conversion function f based on the updated association. After the association is updated by the update unit 403, the inverse conversion function selection unit 402 selects an inverse conversion function f based on the updated association. -1 The updated association is used, so the conversion function f and the inverse conversion function f -1However, other points are similar.

[0145] According to the authentication system S of the third embodiment, the selection server 40 selects the inverse conversion function f -1 and select a transformation function f. This results in an inverse transformation function f -1 Since the authentication server 20 and the user PC 30 do not need to have an algorithm for selecting the inverse conversion function f, the multi-factor authentication mechanism can be simplified. -1 Furthermore, since it becomes easier to change the conversion function f periodically, it becomes more difficult for a third party to guess the conversion mechanism, thereby increasing the security of communication.

[0146] The selection server 40 also determines a selection condition for the first salt, a plurality of conversion functions f and a plurality of inverse conversion functions f -1 This updates the association between each of and the inverse transformation function f -1 The method of selecting the transformation function f is also changed, making it more difficult for a third party to identify the inverse transformation and transformation mechanisms, thereby improving the security of communications.

[0147] [4. Modifications] The present disclosure is not limited to the first to third embodiments described above, and may be modified as appropriate without departing from the spirit and scope of the present disclosure.

[0148] [4-1. Variation 1] For example, in the example of Fig. 11 of the third embodiment, suppose that the selection server 40 receives a conversion function selection request from the user PC 30 immediately before the function database DB3 is updated. In this case, if the selection server 40 receives an inverse conversion function selection request from the authentication server 20 immediately after the function database DB3 is updated, the conversion function f used in the conversion of the TUID and the inverse conversion function f used in the inverse conversion of the converted TUID will be -1 and may not correspond to each other.

[0149] Therefore, in the first modification, when the selection server 40 receives a conversion function selection request from the user PC 30 immediately before the update time of the function database DB3, information on the selection time when the conversion function f was selected may be transmitted to the authentication server 20. The transmission unit 304 further transmits time information on the selection time when the conversion function f was selected to the authentication server 20. The time information is information that can identify whether or not the conversion function f was selected before the function database DB3 was updated. The time information may be transmitted from the selection server 40 to the user PC 30, or may be generated by the user PC 30 if the user PC 30 knows the update time in advance.

[0150] When the inverse conversion function selection unit 402 receives a request from the authentication server 20 immediately after the association in the function database DB3 is updated, the inverse conversion function selection unit 402 selects the first inverse conversion function f -1 , and based on the updated association, a second inverse transformation function f -1 Here, "immediately after" means that the time length is less than a threshold. Therefore, when the time length between the time when the association is updated in the function database DB3 and the time when the request from the authentication server 20 is received and the conversion function f is selected is less than the threshold, this corresponds to "immediately after."

[0151] The inverse conversion function selection unit 402 judges whether the time when the inverse conversion function selection request from the authentication server 20 was received is after the update of the function database DB3. If it is judged that this time is after the update of the function database DB3, the inverse conversion function selection unit 402 selects the first inverse conversion function f based on the association before the update. -1 and the second inverse transformation function f based on the updated association -1 It is assumed that the data storage unit 400 also holds the pre-update function database DB3.

[0152] The inverse transformation function selection unit 208 selects a first inverse transformation function f -1 and the second inverse transformation function f -1If the time information indicates that the conversion function f was selected before the function database DB3 was updated, the inverse conversion function selection unit 208 selects one of the first inverse conversion function f -1 When the time information indicates that the conversion function f was selected after the function database DB3 was updated, the inverse conversion function selection unit 208 selects the second inverse conversion function f -1 Select .

[0153] According to the first modification, when the selection server 40 receives a request from the authentication server 20 immediately after the association in the function database DB3 is updated, the selection server 40 calculates the first inverse conversion function f -1 , and based on the updated association, a second inverse transformation function f -1 The authentication server 20 selects the first inverse transformation function f -1 and the second inverse transformation function f -1 In this way, even if the conversion function f is selected just before the update time, the inverse conversion can be performed accurately. This makes it possible to eliminate the need to redo the multi-factor authentication due to its failure, improving user convenience. The salt server 10, the authentication server 20, the user PC 30, and the selection server 40 also do not execute unnecessary processes, reducing the processing load on these servers.

[0154] [4-2. Variation 2] For example, if the selection time when the conversion function f is selected by the selection server 40 is not immediately before the update time, it is believed that the problem of the first modification will not occur. For this reason, the user PC 30 may not transmit time information to the authentication server 20 when the selection time when the conversion function f is selected is not immediately before the update time, and may transmit time information to the authentication server 20 when the selection time is immediately before the update time. Here, immediately before means that the length of time is less than a threshold. A time length from the selection time to the update time being less than a threshold corresponds to immediately before.

[0155] Whether or not the selection time is immediately before the update time may be determined by the user PC 30, but here it is determined by the selection server 40. It is assumed that the selection server 40 knows the next update time in advance. The selection server 40 receives a conversion function selection request from the user PC 30 and determines whether or not the length of time from the selection time at which the conversion function f is selected to the update time is less than a threshold value. The user PC 30 is notified of the result of this determination.

[0156] If the selected time is not immediately before the update time, the user PC 30 does not need to receive time information from the selection server 40 in the first place. Even if the user PC 30 receives time information from the selection server 40, if the selected time is not immediately before the update time, the user PC 30 does not transmit the time information to the authentication server 20. The user PC 30 receives from the selection server 40 the determination result as to whether the selected time is immediately before the update time. If the selected time is immediately before the update time, the user PC transmits time information to the authentication server 20 as in the first variant.

[0157] If the selection time is not immediately before the update time, the inverse transformation function selection unit 402 selects the second inverse transformation function f -1 Without selecting the first inverse transformation function f -1 If the selection time is immediately before the update time, the first inverse transformation function f -1 and the second inverse transformation function f -1 The selection server 40 holds the result of the determination as to whether the selection time is immediately before the update time. This determination result may be held in association with the first salt received from the user PC 30. If the selection time is not immediately before the update time, the inverse transformation function selection unit 402 selects the first inverse transformation function f -1 When the selection time is immediately before the update time, the inverse transformation function selection unit 402 performs only the process of selecting the first inverse transformation function f -1 and the second inverse transformation function f -1 Select .

[0158] If the selection time is not immediately before the update time, the inverse transformation function selection unit 208 selects the first inverse transformation function f-1 If the selection time is immediately before the update time, the first inverse transformation function f -1 and the second inverse transformation function f -1 If the selection time is not immediately before the update time, the inverse transformation function selection unit 208 selects one of the first inverse transformation functions f -1 Since only the information indicating -1 If the selection time is immediately before the update time, the inverse transformation function selection unit 208 selects the first inverse transformation function f -1 and the second inverse transformation function f -1 Either of the above may be selected.

[0159] According to the second modification, if the selection time is not immediately before the update time, the selection server 40 uses the second inverse transformation function f -1 Without selecting the first inverse transformation function f -1 If the selection time is immediately before the update time, the first inverse transformation function f -1 and the second inverse transformation function f -1 This simplifies the process when the process of the first modification is not necessary. As a result, the processing load on the authentication server 20, the user PC 30, and the selection server 40 can be reduced.

[0160] [4-3. Variation 3] For example, as in the second and third embodiments, the conversion function f and the inverse conversion function f are calculated based on a portion of the first salt. -1 When f is selected, the part may be dynamically changed. That is, in the examples of Fig. 8 and Fig. 11, the conversion function f and the inverse conversion function f are selected based on the last digit of the first salt. -1 The case where the conversion function f and the inverse conversion function f are selected based on the first digit or the second digit of the first salt has been explained. -1 may be dynamically changed so that

[0161] The conversion function selection unit 306 may determine a portion to be used in selecting the conversion function f based on a predetermined determination method, and may select one of the multiple conversion methods based on the determined portion. This determination method may be performed by determining which portion of the first salt is to be used in selecting the conversion function f and the inverse conversion function f. -1 This method of determination may be any predetermined method, such as a method of randomly selecting a predetermined number of digits from the first salt, or a method specified by an administrator.

[0162] In the third modification, the conversion function selection unit 306 determines, based on a predetermined determination method, one digit of the first salt as a part to be used in selecting the conversion function f. The relationship between the value of this one digit and the conversion function f may be the same as that shown in Figs. 8 and 11. The conversion function selection unit 306 selects the conversion function f based on the value of the one digit of the first salt determined based on the predetermined determination method. For example, if the value of this one digit is "1", the conversion function f1 is selected. If the value of this one digit is "7", the conversion function f7 is selected.

[0163] The inverse conversion function selection unit 208 of the authentication server 20 selects the inverse conversion function f based on a predetermined determination method. -1 A portion to be used in the selection of f is determined, and a plurality of inverse transformation functions f are selected based on the determined portion. -1 The method for determining this is the same as that described above. -1 The method of selecting is the same as the method of selecting the transformation function f.

[0164] According to the third modification, the transformation function f and the inverse transformation function f -1 The part used changes dynamically depending on the selection of the transformation function f and the inverse transformation function f -1 This makes it more difficult to identify the mechanism behind the selection, thereby increasing the security of communications.

[0165] [4-4. Variation 4] For example, assume that before a user logs in, the TUID in the user PC 30, the conversion function f, the method of accessing the salt server 10 (for example, the flow of obtaining salt by sending a createSaltPair() command to a specific IP address), and the user's facial photo are stolen by a malicious third party through a cross-site scripting attack or the like. In this case, even if the user updates the TUID every time he or she logs in, the third party will have obtained the series of steps for accessing the salt server 10 and the information required for authentication, which may allow spoofing.

[0166] Therefore, when a user registers information such as a facial photograph in the authentication server 20, or logs in in a secure manner using a user ID and a password, the user PC 30 may generate a hash value based on multiple pieces of information related to the user and transmit it to the authentication server 20. This hash value is associated with the user ID and stored in the user database DB2. When a user performs authentication using a TUID to log in, the user PC 30 converts the TUID and transmits the converted TUID and a hash value based on multiple pieces of information related to the user PC 30 to the authentication server 20. As described in the first embodiment, etc., the transmitting unit 304 also transmits a facial photograph of the user.

[0167] The authentication server 20 acquires the TUID by inversely converting the converted TUID, and executes authentication processing based on the acquired TUID and the hash value. The communication system S described in the first embodiment and the like uses not only TUID authentication but also facial authentication, so the authentication server 20 executes authentication processing based on the TUID, facial features, and the hash value. Therefore, the authentication processing in the fourth modification is three-factor authentication. The authentication using the TUID and facial features is as described in the first embodiment and the like. The authentication server 20 determines whether or not the hash value received from the user PC 30 matches the hash value associated with the user's user ID and stored in the user database DB2. If they match, authentication using the hash value is successful.

[0168] In addition, any information can be combined as the multiple pieces of information for generating a hash value. For example, the user PC 30 may generate a hash value based on multiple pieces of information such as the type of the user PC 30, the type of operating system, and the type of browser. The hash value may also be generated based on other information such as the serial number of the user PC 30, the number of the SIM card, or the MAC address of the communication card. Various hash functions can be used as the hash function for generating the hash value. The hash value is not stored in the user PC 30, but is generated each time authentication is performed.

[0169] According to the communication system S of the fourth modification, security is enhanced by authentication using a hash value. For example, even if a malicious third party illegally obtains the TUID or the like in the user PC 30, there is a high possibility that the hash value cannot be identified, so security is enhanced.

[0170] [4-5. Variation 5] For example, the communication system S can be applied to other scenes other than the scene where the authentication process is executed, such as a scene where an e-mail is sent, a scene where a file is uploaded or downloaded, a scene where a post is made to an SNS, a scene where a page is displayed in a browser, or a scene where a user uploads or downloads personal information.

[0171] For example, if the communication system S is applied to a situation where an e-mail is sent, the first device is a computer that sends the e-mail, and the second device is a computer that receives the e-mail. The original data is the data of the e-mail. The original data includes the body of the e-mail. If an attachment is attached to the e-mail, the original data includes the attachment. The first device performs conversion on the original data, which is an e-mail, based on the second salt to generate converted data. The converted data is the e-mail after conversion. The first device transmits the first salt and the converted data, which is the e-mail after conversion, to the second device. When the second device receives the first salt and the converted data, it acquires the second salt based on the first salt, and performs inverse conversion on the converted data based on the acquired second salt to acquire the e-mail, which is the original data. The method of acquiring the first salt and the second salt is as described in the first to third embodiments and the first to fourth modifications.

[0172] For example, if the communication system S is applied to a situation where a file is uploaded, the first device is a computer of a user who uploads the file, and the second device is a server that receives the file. The original data is the file to be uploaded. The first device performs conversion on the original data, which is the file to be uploaded, based on the first salt, to generate converted data. The converted data is the converted file. The first device transmits the first salt and the converted data, which is the converted file, to the second device. Upon receiving the converted data, the second device acquires a second salt based on the first salt, and performs inverse conversion based on the acquired second salt to acquire the file, which is the original data. The method of acquiring the first salt and the second salt is as described in the first to third embodiments and the first to fourth modifications.

[0173] The same is true when the communication system S is applied to other situations, and the first device converts the original data based on the multiple salts and transmits the converted data to the second device. The second device inversely converts the converted data based on the multiple salts to obtain the original data. The communication system S of the fifth modification example enhances the security of communication in various situations.

[0174] [4-6. Other variations] For example, the first to third embodiments may be combined. The above modified examples may be combined.

[0175] For example, the functions described as being realized by the salt server 10 may be realized by the authentication server 20 or the user PC 30. In this case, the communication system S may not include the salt server 10. For example, if the communication system S includes multiple server computers, the functions may be shared among the multiple server computers. Also, for example, the data described as being stored in the data storage units 100, 200 may be stored by a computer other than the salt server 10 or the authentication server 20.

Claims

1. a receiving unit that receives from the first device converted data generated by converting authentication data related to a user of the first device by the first device, and a hash value based on a plurality of pieces of information related to the first device, the plurality of pieces of information being different types indicating different contents from each other; an inverse conversion unit that inversely converts the converted data to obtain the authentication data; a process execution unit that executes authentication processing for the user based on the acquired authentication data and the hash value; and a selection device, the selection device includes a conversion method selection unit that selects one of a plurality of conversion methods based on a request from the first device; The receiving unit receives, from the first device, the converted data generated by the first device through conversion based on the conversion method selected by the conversion method selection unit; the second device includes an inverse transformation method request unit that requests the selection device to select an inverse transformation method; the selection device further includes an inverse transformation method selection unit that selects one of the plurality of inverse transformation methods based on a request from the second device; the inverse conversion unit inversely converts the converted data based on the inverse conversion method selected by the inverse conversion method selection unit to obtain the authentication data. Communication systems.

2. The process execution unit executes the authentication process based on the hash value received from the first device and a hash value previously stored in a database. The communication system according to claim 1 .

3. The communication system further includes a management device, the management device transmits, to the first device, conversion information for converting the authentication data, based on a request from the first device; The receiving unit receives, from the first device, the converted data generated by the first device through conversion based on the conversion information; the second device further includes an information request unit that requests inverse conversion information for inverse conversion of the converted data from the management device; The management device transmits the inverse conversion information to the second device based on a request from the second device; The inverse conversion unit obtains the authentication data by inversely converting the converted data based on the inverse conversion information received from the management device.

3. A communication system according to claim 1 or 2.

4. a receiving step of receiving, from the first device, converted data generated by converting authentication data related to a user of the first device by the first device, and hash values ​​based on different types of information related to the first device, the multiple pieces of information indicating different contents from each other; an inverse conversion step of inversely converting the converted data to obtain the authentication data; a process execution step of executing an authentication process for the user based on the acquired authentication data and the hash value; is executed by the second device, a conversion method selection step of selecting one of a plurality of conversion methods by a selection device based on a request from the first device; The receiving step receives, from the first device, the converted data generated by the first device through conversion based on the conversion method selected in the conversion method selection step; an inverse transformation method request step is executed by the second device to request the selection device to select an inverse transformation method; an inverse transformation method selection step of selecting one of the plurality of inverse transformation methods by the selection device based on a request from the second device; the inverse conversion step inversely converts the converted data based on the inverse conversion method selected in the inverse conversion method selection step to obtain the authentication data. Communication methods.

5. a receiving unit that receives from the first device converted data generated by converting authentication data related to a user of the first device by the first device, and a hash value based on a plurality of pieces of information related to the first device, the plurality of pieces of information being different types indicating different contents from each other; an inverse conversion unit that inversely converts the converted data to obtain the authentication data; a process execution unit that executes authentication processing for the user based on the acquired authentication data and the hash value; A program for causing a second device to function as a the receiving unit receives from the first device the converted data generated by conversion by the first device based on a conversion method selected by a selection device that selects one of a plurality of conversion methods based on a request from the first device; the program causes the second device to function as an inversion method request unit that requests the selection device to select an inversion method; the inverse conversion unit inversely converts the converted data based on the inverse conversion method selected by the selection device which selects one of the plurality of inverse conversion methods based on the request from the second device, to obtain the authentication data. program.

Images