Communication system, communication method, and program
14 claims: 4 independent, 10 dependent
- 1元データを変換するための変換情報であって、前記元データが変換される第1時点が属する第1期間に応じた第1変換情報を取得する変換情報取得部と、前記第1変換情報に基づいて、前記元データを変換することによって第1変換を行って、第1変換データを生成する変換部と、第2装置に対し、前記第1期間に関する第1期間情報と、前記第1変換データと、を送信する送信部と、を含む第1装置と通信可能であり、前記第1装置から、前記第1期間情報と、前記第1変換データと、を受信する受信部と、前記第1期間情報に基づいて、前記第1変換データを逆変換するための逆変換情報であって、前記第1期間に応じた第1逆変換情報を取得する逆変換情報取得部と、前記第1逆変換情報に基づいて、前記第1変換データを逆変換することによって第1逆変換を行って、前記元データを取得する逆変換部と、を含み、前記第1期間情報は、前記第1期間を特定できないが、複数の前記逆変換情報から前記第1期間に応じた前記第1逆変換情報を特定するための情報である、第2装置。
- 2前記第1時点が前期第1期間の終了間際である場合、前記受信部は、前記第1装置から、前記第1期間情報と、前記第1変換データと、を受信し、前記逆変換情報取得部は、前記第1期間情報に基づいて、前記第1 逆 変換情報を取得し、前記逆変換部は、前記第1逆変換情報に基づいて、前記元データを取得し、前記第1時点が前期第1期間の終了間際でない場合、前記受信部は、前記第1装置から前記第1変換データを受信し、前記逆変換情報取得部は、前記第1 逆 変換情報を取得し、前記逆変換部は、前記第1 逆 変換情報に基づいて、前記元データを取得する、請求項1に記載の第2装置。
- 3前記変換部は、前記第1期間に属し、かつ、前記第1時点とは異なる第2時点に前記元データが変換される場合に、前記元データに対し、前記第1変換を行って、前記第1変換データを生成し、前記変換部は、前記第1期間とは異なる第2期間に属し、かつ、前記第1時点及び前記第2時点とは異なる第3時点に前記元データが変換される場合に、前記元データに対し、前記第2期間に応じた第2変換を行って、第2変換データを生成し、前記逆変換部は、前記第1変換データに対し、前記第1逆変換を行って、前記元データを取得し、前記逆変換部は、前記第2変換データに対し、前記第2期間に応じた第2逆変換を行って、前記元データを取得する、請求項1又は2に記載の第2装置。
- 4前記変換情報取得部は、前記第1期間と、前記元データの一部分と、に応じた前記第1変換情報を取得し、前記第1変換は、前記第1期間及び前記一部分に応じた変換であり、前記受信部は、前記第1装置から、未変換の前記一部分を更に受信し、前記逆変換情報取得部は、前記第1期間と、前記未変換の一部分と、に応じた前記逆変換情報を取得し、前記第1逆変換は、前記第1期間と、前記未変換の一部分と、に応じた逆変換である、請求項1~3の何れかに記載の第2装置。
- 5前記変換部は、前記第1変換情報に基づいて、前記元データのうち、前記一部分以外の残り部分を変換することによって、前記第1変換データを生成し、前記逆変換部は、前記逆変換情報に基づいて、前記第1変換データを逆変換して前記残り部分を取得し、当該残り部分と、前記未変換の一部分と、に基づいて、前記元データを取得する、請求項4に記載の第2装置。
- 6前記変換情報取得部は、複数の期間の各々と、前記変換情報及び前記逆変換情報と、が関連付けられたデータベースにおいて、前記第1期間に関連付けられた前記第1変換情報を取得し、前記逆変換情報取得部は、前記データベースにおいて、前記第1期間に関連付けられた前記第1逆変換情報を取得する、請求項1~5の何れかに記載の第2装置。
- 7前記第1装置は、複数の変換方法の中から、前記第1期間に応じた第1変換方法を選択する変換方法選択部を更に含み、前記変換部は、前記第1変換方法に基づいて、前記元データを変換することによって、前記第1変換を行い、前記第2装置は、複数の逆変換方法の中から、前記第1期間に応じた第1逆変換方法を選択する逆変換方法選択部を更に含み、前記逆変換部は、前記第1逆変換方法に基づいて、前記元データを逆変換することによって、前記第1逆変換を行う、請求項1~6の何れかに記載の第2装置。
- 8前記第1期間は、時間帯で示され、前記変換方法選択部は、前記第1期間が示す時間帯に応じた前記第1変換方法を選択し、前記逆変換方法選択部は、前記第1期間が示す時間帯に応じた前記第1逆変換方法を選択する、請求項7に記載の第2装置。
- 9前記逆変換方法選択部は、前記第1期間情報に基づいて、前記第1期間に応じた前記第1逆変換方法を選択する、請求項7又は8に記載の第2装置。
- 10前記元データは、前記第1装置のユーザに関する認証データであり、前記変換部は、前記認証データに対し、前記第1変換を行って、前記第1変換データを生成し、前記逆変換部は、前記第1変換データに対し、前記第1逆変換を行って、前記認証データを取得し、前記第2装置は、前記第1逆変換により取得された前記認証データに基づいて、前記ユーザに関する認証処理を実行する処理実行部と、前記認証処理が成功した場合に、新たな前記認証データを生成する生成部と、を更に含む請求項1~9の何れかに記載の第2装置。
- 11請求項1~10の何れかに記載の第2装置と、複数の期間の各々と、前記逆変換情報と、を関連付けて管理する第3装置と、を含み、前記第2装置は、前記第3装置に対し、前記逆変換情報を要求する逆変換情報要求部を更に含み、前記第3装置は、前記第2装置に対し、前記第2装置からの要求を受け付けた場合の要求時点が属する前記期間である要求期間に応じた前記逆変換情報と、当該要求期間の前又は後の前記期間に応じた前記逆変換情報と、を含む複数の前記逆変換情報を送信する送信部を更に含み、前記逆変換情報取得部は、前記第1期間情報に基づいて、前記複数の逆変換情報の中から、前記第1逆変換情報を取得する、通信システム。
- 12前記第3装置の前記送信部は、前記要求時点が前記要求期間の区切りの直前であるか直後であるかに応じて、前記要求期間の1つ前の前記期間に関連付けられた前記逆変換情報を送信するか、前記要求期間の1つ後の前記期間に関連付けられた前記逆変換情報を送信するか、を制御する、請求項11に記載の通信システム。
- 13元データを変換するための変換情報であって、前記元データが変換される第1時点が属する第1期間に応じた第1変換情報を取得し、前記第1変換情報に基づいて、前記元データを変換することによって第1変換を行って、第1変換データを生成し、第2装置に対し、前記第1期間に関する第1期間情報と、前記第1変換データと、を送信する第1装置と通信可能な第2装置が、前記第1装置から、前記第1期間情報と、前記第1変換データと、を受信する受信ステップと、前記第1期間情報に基づいて、前記第1変換データを逆変換するための逆変換情報であって、前記第1期間に応じた第1逆変換情報を取得する逆変換情報取得ステップと、前記第1逆変換情報に基づいて、前記第1変換データを逆変換することによって第1逆変換を行って、前記元データを取得する逆変換ステップと、を実行し、前記第1期間情報は、前記第1期間を特定できないが、複数の前記逆変換情報から前記第1期間に応じた前記第1逆変換情報を特定するための情報である、通信方法。
- 14元データを変換するための変換情報であって、前記元データが変換される第1時点が属する第1期間に応じた第1変換情報を取得する変換情報取得部と、前記第1変換情報に基づいて、前記元データを変換することによって第1変換を行って、第1変換データを生成する変換部と、第2装置に対し、前記第1期間に関する第1期間情報と、前記第1変換データと、を送信する送信部と、を含む第1装置と通信可能な第2装置を、前記第1装置から、前記第1期間情報と、前記第1変換データと、を受信する受信部、前記第1期間情報に基づいて、前記第1変換データを逆変換するための逆変換情報であって、前記第1期間に応じた第1逆変換情報を取得する逆変換情報取得部、前記第1逆変換情報に基づいて、前記第1変換データを逆変換することによって第1逆変換を行って、前記元データを取得する逆変換部、として機能させ、前記第1期間情報は、前記第1期間を特定できないが、複数の前記逆変換情報から前記第1期間に応じた前記第1逆変換情報を特定するための情報である、プログラム。
Independent claims14
214 paragraphs, as filed
The present disclosure relates to a communication system, a communication method, and a program.
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.
<p><patcit num="1"><text>Patent No. 4966765</text></patcit><patcit num="2"><text>Patent No. 6866803</text></patcit><patcit num="3"><text>Republished Publication No. 2020-85141</text></patcit></p>
<p>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.</p><p>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.</p><p>One of the objectives of this disclosure is to increase security in communications.</p>
<p>A communication system according to one embodiment of the present disclosure is a communication system including a first device and a second device, wherein the first device includes a conversion unit that performs a first conversion on original data according to a first period to which a first time point to which the original data is converted belongs, to generate first converted data, and a transmission unit that transmits the first converted data to the second device, and the second device includes a receiving unit that receives the first converted data from the first device, and an inverse conversion unit that performs a first inverse conversion on the first converted data according to the first period, to obtain the original data.</p>
<p>According to the present disclosure, security in communications is increased.</p>
<figref num="1">FIG. 1 illustrates an example of an overall configuration of a communication system.</figref><figref num="2">FIG. 2 is a diagram showing an example of a flow of multi-factor authentication in the first embodiment.</figref><figref num="3">FIG. 2 is a functional block diagram illustrating an example of functions implemented in the communication system of the first embodiment. </figref><figref num="4">FIG. 13 is a diagram illustrating an example of a salt database.</figref><figref num="5">FIG. 4 is a diagram illustrating an example of a user database.</figref><figref num="6">FIG. 2 is a diagram illustrating an example of a process executed in the communication system of the first embodiment. </figref><figref num="7">FIG. 2 is a diagram illustrating an example of a process executed in the communication system of the first embodiment. </figref><figref num="8">FIG. 11 is a diagram illustrating an example of a flow of multi-factor authentication in the second embodiment.</figref><figref num="9">FIG. 13 is a diagram illustrating an example of a flow of multi-factor authentication in the third embodiment.</figref><figref num="10">FIG. 11 is a diagram illustrating an example of a functional block realized in a communication system according to a third embodiment. </figref><figref num="11">FIG. 11 is a diagram showing an example of a flow of multi-factor authentication in the first modified example.</figref>
[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 4 described later.
[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.
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.
The salt server 10 is an example of a third device. Therefore, the description of the salt server 10 can be replaced with the description of the third device. The third device may be any device and is not limited to a server computer such as the salt server 10. For example, the third device may be a personal computer, a tablet terminal, or a smartphone.
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.
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.
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.
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.
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.
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.
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.
[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.
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.
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.
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.
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.
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.
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.
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.
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, in order to improve user convenience and prevent the TUID from being stolen by a third party, a salt is used to convert the TUID. 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 a salt is used that corresponds to the day and time period when the user logs in.
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 getSalt() 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.
When the salt server 10 receives a salt request, it refers to the salt database DB1 and acquires a salt corresponding to the current day and time zone. As shown in FIG. 2, the salt database DB1 stores salts for each combination of day and time zone. For example, if one month has 31 days and the 24 hours of one day are divided into one-hour time zones, in the example of FIG. 2, 31×24=744 types of salts are stored in the salt database DB1. If the time when the salt server 10 acquires salts from the salt database DB1 is "December 2, 2021, 01:25:34", the salt server 10 acquires the salt "8414" corresponding to "2nd" and "01:00" and transmits it to the user PC 30.
When the user PC 30 receives the salt "8414" from the salt server 10, it converts the TUID "312456" based on the salt "8414" and a predetermined conversion function f. In the example of FIG. 2, the conversion function f is a function that adds the 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 including the user's face photograph generated by the photographing unit 36 and the converted TUID "320870" to the authentication server 20.
When the authentication server 20 receives the authentication request, it transmits a salt request to the salt server 10. In the example of Fig. 2, the salt request from the user PC 30 to the salt server 10 and the salt request from the authentication server 20 to the salt server 10 have the same format. For this reason, the salt request from the authentication server 20 to the salt server 10 is also made so that the salt conditions are not known, such as getSalt(). By making the format of the salt request common, the API of the salt server 10 can also be common.
When the salt server 10 receives a salt request from the authentication server 20, it refers to the salt database DB1 and acquires salt corresponding to the current day and time zone. If the time when the salt server 10 acquires salt from the salt database DB1 is "December 2, 2021, 01:25:35", the salt server 10 transmits the salt "8414" corresponding to "2nd" and "01:00" to the authentication server 20. This salt "8414" is the same as that transmitted to the user PC 30.
When the authentication server 20 receives the salt "8414" from the salt server 10, the authentication server 20 converts the salt "8414" into an inverse conversion function f<sup>-1</sup>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<sup>-1</sup>is a function that subtracts the salt "8414" from the converted TUID "320870". The authentication server 20 obtains the TUID "312456" by inverse conversion.
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.
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.
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 until the salt is changed. 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 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<sup>-1</sup>In this reverse conversion, the salt 8414 already received from the salt server 10 may be used.
As described above, the communications system S of the first embodiment converts the TUID and reverse-converts the converted TUID based on a salt that corresponds to the combination of the day and time when the user logs in. This ensures that the TUID is not sent as is over the network N, making it difficult for third parties to obtain the TUID. Furthermore, since the salt is only valid for a certain period of time, even if a third party somehow obtains the salt, the period during which the salt is valid can be limited to a certain length, thereby improving the security of communications. The communications system S of the first embodiment will be described in detail below.
[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.
[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, and the update unit 104 are realized mainly by the control unit 11.
[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 in which each of a plurality of time periods is associated with a salt (an example of conversion information and inverse conversion information). The salt server 10 manages each of a plurality of time periods in association with the conversion information and inverse conversion information using the salt database DB1. If the conversion information and inverse conversion information are information called by a name other than salt, the salt server 10 may manage the conversion information and inverse conversion information by using a database called by a name other than the salt database DB1.
4 is a diagram showing an example of the salt database DB1. The salt database DB1 is a database in which salts are stored. For example, the salt database DB1 stores salts for each combination of date and time period. That is, the salt database DB1 associates combinations of date and time period with salts. The salts stored in the salt database DB1 may be updated at a predetermined timing.
In the example of FIG. 4, a case is described in which salts used on past days and times and salts to be used on future days and times are also stored, but only salts used on the current day and time may be stored in the salt database DB1. For example, if the current time is "December 2, 2021, 01:25:34", only salts for "2nd" and "01:00" may be stored in the salt database DB1. In this case, when it becomes "December 2, 2021, 02:00:00", only salts for "2nd" and "02:00" are stored in the salt database DB1.
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, the authentication server 20 and the user PC 30 share a common API so that salt requests of the same format can be received from the authentication server 20 and the user PC 30, but the API for the authentication server 20 and the API for the user PC 30 may be different.
[Salt generation section]
The salt generation unit 101 generates salt based on a predetermined algorithm. For example, the salt generation unit 101 generates salt so that it is a random value. The method of generating the random value itself can use various known methods. For example, it may be a method that uses a timestamp at the time of salt generation, or a method that uses data other than a timestamp. The salt generation unit 101 stores the generated salt in a salt database DB1.
In the first embodiment, the salt generation unit 101 generates a salt for each combination of a future date and time period. The salt generation unit 101 associates this combination with the generated salt and stores it in the salt database DB1. The salt stored in the salt database DB1 may be updated at a predetermined timing by the update unit 104 described later. This timing may be any timing, and may be, for example, the first day of a certain month, the first day of a certain week, or the beginning of a day.
In the first embodiment, a case where the same salt is used for conversion of a TUID and inverse conversion of the converted TUID is taken as an example. Therefore, the salt is an example of conversion information and also an example of inverse conversion information. The part where "salt" is written can be read as conversion information. The part where "salt" is written 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, since the conversion information and the inverse conversion information are the same, 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.
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. If the conversion information and the inverse conversion information are to be based on a combination of a day and a time zone as in the first embodiment, the salt database DB1 stores a combination of the conversion information and the inverse conversion information for each combination of a day and a time zone.
[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 getSalt() is given as an example, but the salt request may be information indicating that salt has been requested. In the first embodiment, a case is described in which the salt request from the authentication server 20 and the salt request from the user PC 30 have the same format, but these formats may be different from each other. The salt request is an example of a request for conversion information and also an example of a request for inverse conversion information. Therefore, the description of the salt request can be replaced with 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.
[Transmitter]
The transmitting unit 103 transmits a salt equivalent to the inverse conversion information to the authentication server 20. The transmitting unit 103 transmits a salt equivalent to the conversion information to the user PC 30. In the first embodiment, the transmitting unit 103 transmits a salt corresponding to the day and time zone to which the salt acquisition time belongs, to each of the authentication server 20 and the user PC 30. The salt acquisition time may be any time between when the salt request is received and when the salt is transmitted. The transmitting unit 103 refers to the salt database DB1 and identifies a combination of the day and time zone to which the salt acquisition time belongs. The transmitting unit 103 transmits a salt associated with the identified combination, to each of the authentication server 20 and the user PC 30.
For example, suppose that the salt server 10 receives a salt request from the authentication server 20 during a first period (in the example of FIG. 2, around 1:00 on the 2nd) to which a certain first time point belongs. The first time point is the time when the salt server 10 receives a salt request from the user PC 30. When the transmission unit 103 receives a salt request from the user PC 30 during the first period, it transmits a first salt to the user PC 30. The first salt is a salt according to the first period. In the example of FIG. 2, since the first period is "01:00 on the 2nd", the first salt is the salt "8414" associated with "01:00 on the 2nd" in the salt database DB1. Hereinafter, when there is no need to distinguish between the first salt according to the first period and other salts according to other periods, it will be simply referred to as salt.
When the transmitting unit 103 receives a salt request from the authentication server 20 in the first period, the transmitting unit 103 transmits a first salt to the authentication server 20. That is, when the transmitting unit 103 receives a salt request from the authentication server 20 and a salt request from the user PC 30 in the same first period, the transmitting unit 103 transmits the same first salt to each of the authentication server 20 and the user PC 30. In the first embodiment, when the transmitting unit 103 receives a salt request from the authentication server 20 and a salt request from the user PC 30 in different periods, the transmitting unit 103 transmits different salts to each of the authentication server 20 and the user PC 30. In this case, the salt used in the conversion of the TUID does not correspond to the salt used in the inverse conversion of the TUID, so that the authentication process fails because the normal inverse conversion is not performed, and the authentication process is restarted.
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.
[Updates]
The update unit 104 updates the salt database DB1. The update unit 104 determines whether a predetermined update condition is satisfied, and updates the salt database DB1 if the update condition is satisfied. The update condition is a condition for updating the salt database DB1. Any condition can be set as the update condition. In the first embodiment, the arrival of midnight every day (the date changing) is taken as an example, but the update condition may be other conditions such as an administrator performing a predetermined operation, an authentication process being executed a predetermined number of times or more, or salt being acquired a predetermined number of times or more.
When the update condition is satisfied, the update unit 104 causes the salt generation unit 101 to generate a salt and stores it in the salt database DB1. It is assumed that the salt generation condition (e.g., timestamp) is different every time the salt database DB1 is updated. Therefore, a different value of salt is generated every time the salt database DB1 is updated. In the data storage example of FIG. 4, when midnight arrives every day, the salt database DB1 is updated so that salt from 00:00 to 23:00 of that day is generated.
[1-3-2. Functions realized in the authentication server]
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 conversion unit 204, a process executing unit 205, a TUID generating unit 206, and a transmitting unit 207 are also realized.
[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.
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.
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.
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.
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<sup>-1</sup>For example, the data store 200 may store an algorithm for generating a TUID.
[Receiver]
The receiving unit 201 receives the converted TUID from the user PC 30. The receiving unit 201 can receive the converted TUID converted with a salt according to an arbitrary period. The converted TUID converted with a salt according to the first period described above is an example of first converted data. Therefore, the part explaining the converted TUID converted with a salt according to the first period can be read as the first converted data. The first converted data is data obtained by performing a first conversion according to the first period on the TUID, which is an example of original data. The original data is data to be converted. 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 sometimes called raw data.
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.
[Salt request section]
The salt requesting unit 202 requests salt from the salt server 10. The salt requesting unit 202 requests salt by transmitting a salt request to the salt server 10. In the first embodiment, the salt requesting unit 202 transmits a salt request to the salt server 10 that does not include information on the salt acquisition rule. For example, when salt according to a combination of a day and a time zone is acquired, the acquisition rule is the combination of a day and a time zone. The salt request does not include information on the day and the time zone, and therefore does not include information on the acquisition rule.
The fact that information regarding the acquisition rule is not included in the salt request is also the case when other acquisition rules are adopted. For example, if a different salt is used for each day without considering the time of day, the acquisition rule will only be the day. Since the salt request does not include information regarding the day, it does not include information regarding the acquisition rule. For example, if a different salt is used for each time of day without considering the day, the acquisition rule will only be the time of day. Since the salt request does not include information regarding the time of day, it does not include information regarding the acquisition rule.
The salt request may include a salt acquisition rule. For example, information that is a seed for generating a salt may be included in the salt request. In this case, if the seeds are not the same, the same salt will not be obtained, so the seed that generated the salt is shared between the authentication server 20 and the user PC 30. For example, as in a second embodiment described later, part of the salt acquisition rule (in the second embodiment, the last two digits of the TUID) may be included in the salt request.
[Salt Acquisition Department]
The salt acquisition unit 203 acquires a first salt, which is a salt for inversely converting the converted TUID and corresponds to a first period. This first salt is an example of first inverse conversion information. 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, of which salt is an example. 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 the key or the password.
In the first embodiment, since the salt server 10 manages the salts, the salt acquisition unit 203 acquires the salts from the salt server 10. The salts 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, and the update unit 104, which have been described as being realized by the salt server 10, are realized by the authentication server 20.
In the first embodiment, the salt acquisition unit 203 acquires salt according to a combination of days and time periods indicated by a first period. The combination of days and time periods is an example of a first period. Therefore, any part that describes a combination of days and time periods can be read as the first period. The first period is a period to which the first point in time at which the salt is acquired belongs. In the first embodiment, an example is given of a case where the first period is indicated by a combination of days and time periods, but the first period may mean only days or only time periods.
The division of the first period is not limited to one hour as in the first embodiment. The length of each period may be longer or shorter than one hour. The length of one period may differ from that of another period. Even if the first period has a meaning other than a combination of days and time periods, the salt acquisition unit 203 may acquire salts according to the first period. The relationship between each period and salt is stored in the salt database DB1.
The salt acquisition unit 203 may acquire a salt according to the first period. For example, the salt acquisition unit 203 acquires a first salt associated with the first period in the salt database DB1. After the salt database DB1 is updated, the salt acquisition unit 203 acquires the first salt associated with the first period in the updated database. If the period to which the salt server 10 accepts a salt request from the authentication server 20 belongs is a second period that is later than the first period, the salt acquisition unit 203 acquires a salt according to the second period.
[Inverse conversion section]
The inverse conversion unit 204 performs a first inverse conversion according to the first period on the converted TUID, which is an example of first converted data, to obtain the original data and the TUID, which is an example of authentication data. The first inverse conversion is an inverse conversion according to the first conversion. The first inverse conversion is decryption in cryptography. If the time point when the authentication server 20 inverse converts the converted TUID is a second period that is later than the first period, the inverse conversion unit 204 performs a second inverse conversion according to the second period on the second converted data to obtain the original data.
The inverse conversion unit 204 performs a first inverse conversion by inversely converting the converted TUID based on the first salt corresponding to the first period.<sup>-1</sup>is stored in the data storage unit 200. The inverse conversion unit 204 converts the converted TUID into an inverse conversion function f<sup>-1</sup>In the example of Fig. 2, the inverse conversion unit 204 subtracts the first salt from the converted TUID to perform an inverse conversion on the converted TUID and obtain the TUID.
The inverse transformation itself is performed using various inverse transformation functions f<sup>-1</sup>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<sup>-1</sup>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.
[Processing execution section]
The process execution unit 205 executes authentication processing for the user based on the authentication data acquired by the first 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. In addition, 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.
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.
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.
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.
[TUID generation part]
If the authentication process is successful, the TUID generation unit 206 generates a new TUID. 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 TUID.
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.
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.
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.
[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.
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.
[1-3-3. Functions realized on user PC]
The data storage unit 300 is realized mainly by the storage unit 32. The salt request unit 301, the salt acquisition unit 302, the conversion unit 303, the transmission unit 304, and the reception unit 305 are realized mainly by the control unit 31.
[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.
[Salt request section]
The salt requesting unit 301 requests salt from the salt server 10. The salt requesting unit 301 requests salt by transmitting a salt request to the salt server 10. In the first embodiment, the salt requesting unit 301 transmits a salt request that does not include information on the salt acquisition rule to the salt server 10. This is similar to the salt requesting unit 202 of the authentication server 20. Other points regarding the salt request are as described in the processing of the salt requesting unit 202.
In the first embodiment, the salt request unit 301 requests a salt from the salt server 10 when a facial photograph is generated by the photographing unit 36. The salt request unit 301 may request a salt at any timing, and is not limited to the timing when a facial photograph is generated. For example, the salt request unit 301 may request a salt 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.
[Salt Acquisition Department]
The salt acquisition unit 302 acquires a first salt, which is a salt for converting a TUID, which is an example of original data, corresponding to a first period. This first salt is an example of first conversion information. 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 the key or the password.
In the first embodiment, since the acquisition of salts from the salt server 10 to the user PC 30 and the acquisition of salts from the salt server 10 to the authentication server 20 are performed in the same procedure, the processing of the salt acquisition unit 302 is similar to the processing of the salt acquisition unit 203 of the authentication server 20. Therefore, they are also similar in terms of acquiring salts from the salt server 10 and acquiring salts according to a combination of a day and a time zone.
In the first embodiment, the first period is indicated by a combination of a day and a time period, so the salt acquisition unit 302 acquires a first salt according to the combination of a day and a time period indicated by the first period. The salt acquisition unit 302 acquires a first salt associated with the first period in the salt database DB1. After the salt database DB1 is updated, the salt acquisition unit 302 acquires a first salt associated with the first period in the updated salt database DB1. The salt acquisition unit 302 acquires the first salt from the salt server 10.
[Conversion section]
The conversion unit 303 performs a first conversion on the original data and the TUID, which is an example of authentication data, according to a first period to which a first point in time to which the TUID is converted belongs, to generate first converted data. The first conversion is a conversion according to the first period. In the first embodiment, the conversion based on a first salt according to the first period corresponds to the first conversion. The first conversion is performed if the second point in time is different from the first point in time but belongs to the same first period as the first point in time. Therefore, when the TUID is converted to a second point in time that belongs to the first period and is different from the first point in time, the conversion unit 303 performs the first conversion on the TUID to generate first converted data.
On the other hand, if the second period is different from the first period, a second conversion different from the first conversion is performed. Therefore, when the TUID belongs to a second period different from the first period and is converted to a third time point different from the first time point and the second time point, the conversion unit 303 performs a second conversion on the TUID according to the second period to generate second converted data. In the first embodiment, the conversion based on the second salt according to the second period corresponds to the second conversion. The conversion function f itself is the same in the first conversion and the second conversion, but the salt input to the conversion function f is the first salt in the case of the first conversion and the second salt in the case of the second conversion, so that the first conversion and the second conversion are different from each other. That is, the first salt, which is an example of the first conversion information used in the first conversion, and the second salt, which is an example of the second conversion information used in the second conversion, are different from each other.
The conversion unit 303 performs the first conversion by converting the TUID based on the first salt. The conversion is encryption in cryptography. The conversion may be any conversion in which some change is made to the TUID. For example, inputting the TUID into some function, changing part of the TUID, changing the entire TUID, adding some information to the TUID, or deleting part of the TUID corresponds to the conversion. The inverse conversion may be any process in the opposite direction to these (process of restoring the TUID to its original state). As described above, compressing a file may correspond to the conversion, and decompressing a file may correspond to the inverse conversion. In this case, the compression or decompression is performed using the first salt as a password.
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 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.
[Transmitter]
The transmitting unit 304 transmits the converted TUID to the authentication server 20. For example, the transmitting unit 304 transmits the converted TUID and a facial photograph to the authentication server 20. In the first embodiment, a case where the converted TUID and the facial photograph are included in the authentication request is taken as an example. For this reason, the transmitting unit 304 transmits the converted TUID and the facial photograph by transmitting an authentication request including the converted TUID and the facial photograph to the authentication server 20. The transmitting unit 304 does not need to transmit the converted TUID and the facial photograph together as one piece of data. The transmitting unit 304 may transmit the converted TUID and the facial photograph separately. Note that the facial photograph may also be converted based on a 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.
[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.
[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. It is also assumed that salts have already been stored in the salt database DB1.
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).
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.
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 transmits a salt according to the current day and time zone to the user PC 30 based on the salt database DB1 (S11). Upon receiving the salt from the salt server 10 (S12), the user PC 30 converts the TUID stored in the storage unit 32 based on the salt (S13).
7, the user PC 30 transmits an authentication request including the TUID converted 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 to the salt server 10 (S16). Upon receiving the salt request (S17), the salt server 10 transmits a salt according to the current day and time zone to the authentication server 20 based on the salt database DB1 (S18).
When the authentication server 20 receives the salt from the salt server 10 (S19), it inversely converts the converted TUID included in the authentication request received in S15 based on the salt (S20). The authentication server 20 executes multi-factor authentication based on the TUID inversely converted in S20 and the face photo 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 face photo 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.
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.
According to the communication system S of the first embodiment, the user PC 30 performs a first conversion on the TUID according to a first period to generate a converted TUID. The user PC 30 transmits the converted TUID to the authentication server 20. The authentication server 20 receives the converted TUID from the user PC 30. The authentication server 20 performs a first inverse conversion on the converted data according to the first period to obtain the TUID. This increases the security of communications because the converted TUID is transmitted over the network and cannot be obtained by a third party. Even if a third party somehow obtains the mechanism for the first conversion, the period during which this mechanism can be used is limited, so that the period during which fraud can occur can be limited to a certain extent, thereby increasing the security of communications.
Furthermore, user PC 30 performs the first conversion even if the first and second points in time are different from each other, as long as they belong to the same first period. User PC 30 performs the second conversion on the TUID when the TUID is converted to a third point in time that belongs to a second period different from the first period. Authentication server 20 performs the first inverse conversion in the first period to obtain the TUID. Authentication server 20 performs the second inverse conversion in the second period to obtain the TUID. This allows different conversions to be performed in the first and second periods, so that even if a third party somehow obtains the mechanism of the first conversion, the first conversion will no longer be available in the second period, thereby improving security in communications.
The user PC 30 also performs a first conversion by converting the TUID based on the first salt. The authentication server 20 performs a first inverse conversion by inversely converting the converted TUID based on the first salt. As a result, the conversion function f and the inverse conversion function f<sup>-1</sup>By changing the salt used depending on the period without changing the value, the security of communication is improved.
Furthermore, each of the authentication server 20 and the user PC 30 obtains a first salt according to the combination of date and time period indicated by the first period. This allows the period during which the first salt is valid to be set on a time-period basis, making it possible to set a relatively short period during which the first salt is valid. Even if a third party obtains the first salt, the period during which the first salt can be used is short, effectively enhancing security in communications.
Furthermore, each of the authentication server 20 and the user PC 30 acquires a first salt associated with the first period in the salt database DB1. By storing the first salt in advance in the salt database DB1, it is no longer necessary to generate the first salt on the spot, and therefore the processing required during communication can be simplified. As a result, the processing load on the salt server 10 is reduced, and the time required to complete the authentication processing is shortened.
In addition, the salt server 10 updates the salt database DB1, which prevents the same salt from being used for a long period of time, thereby improving security in communication.
Furthermore, each of the authentication server 20 and the user PC 30 transmits a salt request to the salt server 10. The salt server 10 transmits a first salt to each of the authentication server 20 and the user PC 30. Each of the authentication server 20 and the user PC 30 obtains the first salt from the salt server 10. This eliminates the need for the authentication server 20 to manage the first salt, and therefore the processing load in communication can be distributed. In other words, the processing required for communication can be distributed between the salt server 10 and the authentication server 20. This reduces the processing load on the authentication server 20.
Furthermore, each of the authentication server 20 and the user PC 30 transmits a salt request that does not include information regarding the first salt acquisition rule to the salt server 10. This makes it difficult for a malicious third party to decipher the TUID conversion mechanism even if the salt request is stolen. For example, even if a salt according to the day and time period has been acquired, the acquisition rule cannot be ascertained from the salt request alone, which further enhances security in communication.
Furthermore, the authentication server 20 executes authentication processing based on the TUID acquired by the first inverse conversion, 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.
[2. Second embodiment]
In the first embodiment, a case where a salt according to a date and a time period is used is described. The method of acquiring the salt is not limited to the example of the first embodiment. In the second embodiment, a case where a salt according to a combination of the date on which the salt is acquired and a part of the TUID is used is described. In the second and third embodiments described below, explanations of the same points as in the first embodiment are omitted.
FIG. 8 is a diagram showing an example of the flow of multi-factor authentication in the second embodiment. As shown in FIG. 8, the general flow is similar to that of the first embodiment, but the method of acquiring the salt is different from that of the first embodiment. For example, the salt database DB1 stores a salt for each combination of the date and the last two digits of the TUID. The user PC 30 transmits a salt request including the last two digits of the TUID "312400", "00", to the salt server 10. Even if a malicious third party steals the last two digits of the TUID, they cannot steal the TUID itself, and they cannot understand the salt acquisition rule from the number "00" alone.
When the salt server 10 receives a salt request, it refers to the salt database DB1 and obtains a salt according to the combination of the current date and the last two digits of the TUID included in the salt request. In the example of Fig. 8, the salt server 10 transmits to the user PC 30 the salt "6435" according to the "2nd", which is the date when the salt server 10 received the salt request from the user PC 30, and the last two digits of the TUID, "00".
When the user PC 30 receives the salt "6435" from the salt server 10, it converts the TUID "312400" based on this salt "6435." In the example of Fig. 8, a conversion function f is used that adds the last two digits of the TUID, "00," to "9559," which is obtained by adding the salt "6435" to the first four digits of the TUID, "3124," so the converted TUID becomes "955900." The user PC 30 transmits an authentication request to the authentication server 20, which includes the user's facial photograph generated by the photographing unit 36 and the converted TUID, "955900."
When the authentication server 20 receives the authentication request, it sends a salt request including the last two digits "00" of the converted TUID "955900" to the salt server 10. When the salt server 10 receives the salt request, it refers to the salt database DB1 and sends to the authentication server 20 the salt "6435" corresponding to the combination of the current day, "2nd", and the last two digits of the TUID included in the salt request, "00".
When the authentication server 20 receives the salt "6435" from the salt server 10, it reverse-converts the converted TUID "955900" received from the user PC based on this salt "6435." In the example of FIG. 8, a conversion function f<sup>-1</sup>is used. The authentication server 20 obtains the first four digits of the TUID, "3124", by reverse conversion. The authentication server 20 adds the last two digits of the TUID, "00", to the first four digits of the TUID, "3124", to obtain the TUID, "312400". The subsequent flow of multi-factor authentication is the same as in the first embodiment.
The functional blocks of the second embodiment are the same as those of the first embodiment. The salt acquisition units 203, 302 acquire a salt according to the last two digits of the TUID. The last two digits of the TUID are an example of a portion of the TUID. Therefore, the description of the last two digits of the TUID can be read as the portion of the TUID. The portion of the TUID may be any portion and is not limited to the last two digits of the TUID. For example, it may be the first digit of the TUID, or the second to fourth digits of the TUID. The portion of the TUID does not have to be consecutive digits, such as the first and last digits of the TUID. The length of the portion of the TUID may also be any length.
In the second embodiment, the salt acquisition units 203, 302 acquire salts according to the date when the salt is acquired (an example of a first period) and the last two digits of the TUID (an example of a part of the original data), but the salt acquisition units 203, 302 may acquire salts according to the time period when the salt is acquired and the last two digits of the TUID. In this case, it is assumed that the salt database DB1 defines a salt for each of these combinations. By combining the first and second embodiments, the salt acquisition units 203, 302 may acquire salts according to three combinations of the date, the time period, and the last two digits of the TUID. In this case, it is assumed that the salt database DB1 defines a salt for each of these three combinations.
The first conversion in the second embodiment is a conversion according to the first period and a portion of the TUID. The conversion unit 303 generates first converted data by converting the remaining portion of the TUID other than the last two digits based on the first conversion information. The remaining portion is a portion other than a portion of the original data. If the TUID is six digits, the remaining portion is the first four digits. The conversion method itself using the salt is as described in the first embodiment.
The transmission unit 304 further transmits the last two digits of the unconverted TUID to the authentication server 20. These last two digits correspond to plaintext in cryptography. In the second embodiment, a case will be described in which these last two digits are included as the last two digits of the converted TUID, but these last two digits may be transmitted as information separate from the converted TUID. Even in the case in which these last two digits are transmitted as being included in the converted TUID, they may be added to a position (for example, the first two digits) different from the original position (the last two digits). These last two digits are an example of a portion of the unconverted part. Therefore, any description of these last two digits can be read as a portion of the unconverted part. As described above, this portion is not limited to the last two digits.
The receiving unit 201 further receives the last two digits of the unconverted TUID from the user PC 30. In the second embodiment, the last two digits of the unconverted TUID are included as part of the converted TUID, and so the receiving unit 201 receives the last two digits of the unconverted TUID by receiving the converted TUID. If the last two digits of the unconverted TUID are transmitted as information different from the converted TUID, the receiving unit 201 only needs to receive the last two digits of the unconverted TUID transmitted as the different information. The salt acquiring unit 203 acquires a salt according to the date on which the salt is acquired (an example of a first period) and the last two digits of the unconverted TUID. The method of acquiring the salt by the salt acquiring unit 203 is similar to the method of acquiring the salt by the salt acquiring unit 302.
The first inverse conversion of the second embodiment is an inverse conversion according to the first period and a portion of the unconverted data. Based on the inverse conversion information, the inverse conversion unit 204 inversely converts the remaining portion (the upper four digits) of the converted TUID, which is an example of the first converted data, to obtain the remaining portion, and obtains the TUID based on the remaining portion and the portion of the unconverted data. In the example of FIG. 8, the inverse conversion unit 204 obtains the upper four digits of the TUID, "3124", by inverse conversion, and therefore obtains the TUID, "312400", based on the upper four digits, "3124", and the last two digits, "00", received from the user PC 30. In the example of FIG. 8, a case is described in which the upper four digits, "3124", and the last two digits, "00", are added, but the TUID, which is the original data, may be obtained based on a predetermined combination rule.
According to the communication system S of the second embodiment, the user PC 30 obtains a first salt according to the first period and the last two digits of the TUID, and transmits the last two digits of the unconverted TUID. The authentication server 20 receives the last two digits of the unconverted TUID from the user PC 30, and obtains a first salt according to the first period and the last two digits of the unconverted TUID. This increases the security of multi-factor authentication because the converted TUID is transmitted over the network, making it difficult for a third party to obtain the TUID. Even if a malicious third party steals a salt request, it is difficult for the conversion mechanism to be understood from only the last two digits of the TUID, thereby further increasing the security of communications.
Furthermore, user PC 30 generates the first four digits of the converted TUID by converting the first four digits, which are the remaining portion of the TUID other than the last two digits, based on the first salt. Authentication server 20 inversely converts the first four digits of the converted TUID based on the first salt to obtain the first four digits of the TUID, and obtains the TUID based on these first four digits and the unconverted last two digits. In this way, even if the TUID is divided into multiple parts, authentication server 20 can obtain a single combined TUID and complete the authentication process reliably.
[3. Third embodiment]
In the first and second embodiments, the case where security in communication is enhanced by devising a method for acquiring a salt has been described. The method for enhancing security in communication is not limited to the examples of the first and second embodiments. In the third embodiment, the user PC 30 enhances security in communication by using different conversion functions f depending on the time period for converting the TUID. The user PC 30 stores multiple conversion functions f in advance and can convert the TUID using any of the conversion functions f.
FIG. 9 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 first and second embodiments. In the example of FIG. 9, a method of acquiring a salt similar to that of the first embodiment is taken as an example. The flow until the user PC 30 acquires the salt is similar to that of the first embodiment. The user PC 30 acquires the salt "8414" corresponding to the current date "2nd" and time zone "01:00" from the salt server 10.
In the third embodiment, the user PC 30 uses different conversion functions f based on the time period for converting the TUID. For example, the user PC 30 stores conversion functions f0 to f23 corresponding to the time periods "00:00" to "23:00", respectively. Hereinafter, when the conversion functions f0 to f23 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 same salt is used, if the conversion functions f are different, the value of the converted TUID will also be different.
In the example of Fig. 9, the time zone for converting the TUID is "01:00", so the user PC 30 selects conversion function f1 from among conversion functions f0 to f23. It is assumed that conversion function f1 is the same as conversion function f described in Fig. 2 of the first embodiment. Therefore, the user PC 30 converts the TUID in the same manner as in the first embodiment, and transmits the converted TUID to the authentication server 20. Upon receiving the converted TUID, the authentication server 20 obtains a salt from the salt server 10 in the same manner as in the first embodiment.
In the third embodiment, the authentication server 20 calculates an inverse conversion function f based on the time zone for converting the TUID.<sup>-1</sup>For example, the authentication server 20 uses the inverse conversion functions f<sup>-1</sup>0~f<sup>-1</sup>23 is stored. From now on, the inverse transformation function f<sup>-1</sup>0~f<sup>-1</sup>When 23 is not distinguished, simply use the inverse transformation function f<sup>-1</sup>Each inverse transformation function f<sup>-1</sup>The calculation methods shown by are different. Therefore, even if the salt is the same, the inverse transformation function f<sup>-1</sup>If the TUID is different, the TUID value after inverse conversion will also be different.
Individual inverse transformation functions f<sup>-1</sup>The calculation method indicated by corresponds to the conversion function f that assumes the same time zone. In order to obtain an accurate TUID, the inverse conversion function f corresponding to the conversion function f used by the user PC 30 is used.<sup>-1</sup>In the example of Figure 9, the time period for which the TUID is to be inversely converted is "01:00", so the inverse conversion function f<sup>-1</sup>0~f<sup>-1</sup>Of 23, inverse transformation functions<sup>-1</sup>Select f1. The inverse transformation function f<sup>-1</sup>1 corresponds to the conversion function f1 used by the user PC 30. Therefore, the authentication server 20 can convert the TUID and obtain the correct TUID in the same manner as in the first embodiment. The subsequent flow of multi-factor authentication is the same as in the first embodiment.
Fig. 10 is a diagram showing an example of functional blocks realized in a communication system S of the third embodiment. As shown in Fig. 10, in the third 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.
The conversion function selection unit 306 selects a first conversion method according to the first period from among a plurality of conversion functions f. The conversion function f is an example of the first 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 formula not called a function, or an encryption algorithm. For another example, the conversion method may be a file compression algorithm.
The conversion function selection unit 306 may select one of a plurality of conversion functions f based on a predetermined selection method. In the third embodiment, a case where a time period is used will be described as an example of the selection method. The conversion function selection unit 306 selects a conversion function f according to the time period. It is assumed that the relationship between the time period 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 current time period. In the third embodiment, the numerical values "00" to "23" indicated by the time period correspond to the numerical values included in the conversion functions "f0" to "f23".
In the third embodiment, the time period is an example of the first period. Therefore, the part describing the time period can be read as the first period. In the third embodiment, the case where the first period is indicated by the time period will be described, but the first period may be indicated by a combination of the day and the time period as in the first and second embodiments, or may be indicated by only the day. Even if the first period has another meaning, the conversion function selection unit 306 selects the conversion function f according to the time period indicated by the first period. It is assumed that the relationship between each period and the conversion function f is defined in advance in the data storage unit 300.
The conversion unit 303 performs a first conversion by converting the TUID based on the conversion function f selected by the conversion function selection unit 306. This embodiment differs from the first and second embodiments in that the conversion function f selected by the conversion function selection unit 306 is used, but is similar in other respects.
The inverse transformation function selection unit 208 selects a plurality of inverse transformation functions f<sup>-1</sup>Among them, the inverse transformation function f<sup>-1</sup>Select the inverse transformation function f<sup>-1</sup>is an example of the first inverse transformation method. Therefore, the inverse transformation function f<sup>-1</sup>The first inverse transformation method is a method for inversely transforming a transformed TUID. The inverse transformation method may be any method that defines how to inversely transform a transformed TUID, and may be implemented using an inverse transformation function f<sup>-1</sup>However, 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.
The inverse transformation function selection unit 208 selects a plurality of inverse transformation functions f<sup>-1</sup>In the third embodiment, a case where a time period is used as an example of a selection method will be described. The inverse conversion function selection unit 208 selects an inverse conversion function f<sup>-1</sup>Select the time zone and inverse transformation function f<sup>-1</sup>The relationship is assumed to be defined in advance in the data storage unit 200. The inverse transformation function selection unit 208 selects the inverse transformation function f<sup>-1</sup>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.<sup>-1</sup>Then, the inverse transformation function f<sup>-1</sup>Select .
The inverse transformation unit 204 selects the inverse transformation function f<sup>-1</sup>The first inverse transformation is performed by inversely transforming the transformed TUID based on the inverse transformation function f<sup>-1</sup>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.
According to the communication system S of the third embodiment, the user PC 30 selects a conversion function f according to the first period from among a plurality of conversion functions f, and converts the TUID. The authentication server 20 selects a conversion function f according to the first period from among a plurality of inverse conversion functions f<sup>-1</sup>Among them, the inverse transformation function f<sup>-1</sup>and then reverse-converts the converted TUID. As a result, the converted TUID is sent over the network, making it difficult for a third party to obtain the TUID, thus improving communication security. In addition, because the conversion function f changes dynamically, it becomes difficult for a third party to understand how the conversion works, further improving communication security.
In addition, the user PC 30 selects a conversion function f according to the time period indicated by the first period. The authentication server 20 selects an inverse conversion function f according to the time period indicated by the first period.<sup>-1</sup>This causes the conversion function f to change depending on a shorter period, so that the frequency of reusing the same conversion function f is further reduced, making it difficult for a third party to understand the mechanism of the conversion.
[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.
[4-1. Variation 1]
For example, in the example of FIG. 2 of the first embodiment, the time when the salt request from the user PC 30 was accepted was "December 2, 2021, 01:59:59" and the time when the salt request from the authentication server 20 was accepted was "December 2, 2021, 02:00:00". In this case, the salt acquired by the user PC 30 is "8414", and the salt acquired by the authentication server 20 is "9436". In this case, the salt used in the conversion of the TUID and the salt used in the inverse conversion of the converted TUID are different, so the authentication server 20 cannot acquire an accurate TUID. Therefore, in the first modification, a case will be described in which information capable of identifying the time zone of the salt used in the conversion of the TUID is transmitted from the user PC 30 to the authentication server 20.
11 is a diagram showing an example of the flow of multi-factor authentication in Modification 1. In Modification 1, the flow until the salt server 10 receives a salt request from the user PC 30 is the same as in the first embodiment. When the salt server 10 receives a salt request from the user PC 30, it transmits to the user PC 30 a first salt corresponding to the day and time zone to which the current time belongs, and a second salt corresponding to the next time zone.
In the example of FIG. 11, the time when the salt request from the user PC 30 was accepted is "December 2, 2021, 01:59:59". The salt server 10 transmits a pair of the first salt "8414" corresponding to "2nd" and "01:00" and the second salt "9436" corresponding to the next time period "2nd" and "02:00" to the user PC 30. The user PC 30 receives the pair of salts "8414" and "9436" from the salt server 10.
The user PC 30 selects one of the salt pair "8414" and "9436". The user PC 30 may select a salt based on a predetermined selection method. In the first modification, an example is given in which it is determined that the first salt is to be selected, but the salt may be selected based on other selection methods. For example, the user PC 30 may select a salt based on the time when the salt request is sent, the time when the salt pair is received, or the time when the salt is selected.
In the example of FIG. 11, the user PC 30 converts the TUID "312456" based on the first salt "8414". The converted TUID becomes "320870". The user PC 30 transmits the converted TUID "320870" and a timestamp "59:59" that can identify the time zone corresponding to the first salt "8414" to the authentication server 20. This timestamp may be the current time "December 2, 2021 01:59:59", but in order to reduce the information available to a third party, only "59:59" is transmitted. The timestamp may be any of the time when the salt request is transmitted, the time when the salt is received, the time when the TUID is converted, or the time when the converted TUID is transmitted.
When the authentication server 20 receives the converted TUID "320870" and the timestamp "59:59", it transmits a salt request to the salt server 10. When the salt server 10 receives the salt request from the authentication server 20, it transmits to the authentication server 20 a pair of a salt corresponding to the day and time zone to which the current time belongs, and a salt corresponding to the next or previous time zone.
In the example of FIG. 11, the time when the salt request from the authentication server 20 is accepted is "December 2, 2021, 01:59:59". In this case, the salt server 10 transmits a pair of the first salt "8414" corresponding to "2nd" and "01:00" and the second salt "9436" corresponding to the next time period, "2nd" and "02:00", to the authentication server 20. The authentication server 20 receives the pair of salts "8414" and "9436" from the salt server 10.
On the other hand, suppose that the time when the salt request from the authentication server 20 was accepted was "2021-12-2 02:00:00". In this case, the salt server 10 transmits to the authentication server 20 a pair of the first salt "8414" corresponding to the previous time zone "2nd" and "01:00", and the second salt "9436" corresponding to the time zone to which the current time belongs "2nd" and "02:00". The authentication server 20 receives the pair of salts "8414" and "9436" from the salt server 10. In this way, the salt server 10 may control whether to transmit the salt of the previous time zone or the salt of the next time zone depending on whether it is immediately before or after the time zone division.
The authentication server 20 can determine from the time stamp "59:59" received from the user PC 30 that a salt from a relatively earlier time period was used in the conversion. In other words, it can determine that the first salt of the pair of salts received from the authentication server 20 was used. The authentication server 20 executes a reverse conversion of the converted TUID "320870" based on the first salt "8414". The subsequent flow is the same as in the first embodiment.
On the other hand, suppose the timestamp received from the user PC 30 is "00:00". In this case, the user PC 30 converts the TUID "312456" using the salt "9436" instead of the salt "8414". In this case, the authentication server 20 can determine, based on this timestamp, that a salt from a relatively later time period was used in the conversion. That is, the authentication server 20 performs a reverse conversion based on the second salt "9436".
In the example of FIG. 11, it is assumed that the time when the salt server 10 received the salt request from the user PC 30 was "December 1, 2021, 23:59:59". The salt server 10 transmits to the user PC 30 the first salt "8201" corresponding to "1st" and "23:00", and the second salt "6435" corresponding to the next day's "2nd" and "00:00".
The transmitting unit 304 further transmits first period information regarding the first period to the authentication server 20. In the example of FIG. 11, "01:00" on "the 2nd" corresponds to the first period. The first period information is information that can identify which period of salt should be used. In the example of FIG. 11, the timestamp "59:59" corresponds to the first period information. Therefore, the part explaining the timestamp "59:59" can be read as the first period information.
The receiving unit 201 further receives first period information from the user PC 30. In the example of Fig. 11, the receiving unit 201 receives a timestamp "59:59" as the first period information from the user PC 30. When the receiving unit 201 receives the first period information, the salt requesting unit 202 requests salt from the salt server 10. The salt request is as described in the first to third embodiments.
When the salt server 10 receives a request from the authentication server 20 during a second period that is later than the first period, the salt server 10 transmits to the authentication server 20 a plurality of salts including a salt corresponding to the first period and a salt corresponding to the second period. The combination of a day and a time period is an example of the second period. Therefore, any description of the combination of a day and a time period can be read as the second period.
In the example of FIG. 11, the first period is "01:00" on the "2nd". The end point of this first period is the point just before "02:00:00" on the "2nd" (for example, "01:59:59" on the "2nd"). In the example of FIG. 11, since the first point in time, "December 2, 2021 01:59:59", is the same as or close to this end point, the salt server 10 transmits the salt "8414" for "01:00" on the "2nd", which is the first period, and the salt "9436" for "02:00" on the "2nd", which is the second period following the first period.
For example, if the salt server 10 is immediately after the start of the first period, the salt server 10 transmits a plurality of salts including a salt according to the first period and a salt according to a third period before the first period. Immediately after the start means within a predetermined time (for example, within a few seconds to one minute) from the start of the first period. For example, in the example of FIG. 11, assume that the first time point is "December 2, 2021, 02:00:00" instead of "December 2, 2021, 01:59:59". In this case, the first period is "02:00" on the "2nd". The start time of this first period is "02:00:00" on the "2nd". Since the first point in time, "December 2, 2021, 02:00:00", is the same as or immediately after this start point, the salt server 10 transmits the salt "8414" for "01:00" on "2nd", which is the third period before the first period, and the salt "9436" for "02:00" on "2nd", which is the first period.
The salt acquisition unit 203 acquires a salt according to the first period based on the first period information. The salt acquisition unit 203 acquires a salt according to the first period from among a plurality of salts received from the salt server 10 based on the first period information. In the example of FIG. 11, the salt acquisition unit 203 selects one of the pairs of salts received from the salt server 10 based on the first period information. In the example of FIG. 11, the salt acquisition unit 203 can specify that a chronologically earlier salt should be selected based on the timestamp "59:59". Therefore, the salt acquisition unit 203 selects the first salt "8414". The inverse conversion process after the salt "8414" is selected is the same as in the first to third embodiments.
On the other hand, in the example of FIG. 11, suppose the timestamp is "00:00" instead of "59:59". In this case, the salt acquisition unit 203 can determine from the timestamp "00:00" that a later salt should be selected. Therefore, the salt acquisition unit 203 selects the second salt "9436". The inverse conversion process after the salt "9436" is selected is the same as in the first to third embodiments.
According to the communication system S of the first modification, the user PC 30 further transmits a time stamp, which is an example of first period information, to the authentication server 20. The authentication server 20 acquires the first salt based on the time stamp received from the user PC 30. This allows the reverse conversion to be performed accurately even if the first salt is acquired just before the end of a certain time period. This eliminates the need to redo the multi-factor authentication after it fails, improving user convenience. The salt server 10, the authentication server 20, and the user PC 30 also do not execute unnecessary processes, reducing the processing load on these devices.
Furthermore, when the salt server 10 receives a salt request from the authentication server 20 during a second period that is later than the first period, the salt server 10 transmits to the authentication server 20 a plurality of salts including a salt corresponding to the first period and a salt corresponding to the second period. The authentication server 20 selects a first salt to be used in reverse conversion from among the plurality of salts based on a timestamp, which is an example of first period information. This allows the reverse conversion to be performed accurately, thereby eliminating the need to redo the multi-factor authentication if it fails.
[4-2. Variation 2]
For example, in the third embodiment (FIG. 9), the transformation function f and the inverse transformation function f<sup>-1</sup>Even when the above is selected, the same problem as in the first modification may occur. For example, assume that the time when the user PC 30 performs the conversion is "December 2, 2021, 01:59:59" and the time when the authentication server 20 performs the inverse conversion is "December 2, 2021, 02:00:00". In this case, the conversion function f of the TUID and the inverse conversion function f of the converted TUID are<sup>-1</sup>Since and do not correspond, there is a possibility that the authentication server 20 will not be able to obtain an accurate TUID.
Therefore, in the second modification, similarly to the first modification, the user PC 30 transmits the time stamp "59:59" to the authentication server 20. With this time stamp, even if the time when the inverse conversion is performed is "2021-12-2 02:00:00", the authentication server 20 can use the inverse conversion function f<sup>-1</sup>The transmitting unit 304 further transmits the first period information to the authentication server 20.
If the timing when the salt request was sent from the user PC 30 to the salt server 10 was as shown in FIG. 11, then "01:00" on "2nd" corresponds to the first period.<sup>-1</sup>In the above example, the timestamp "59:59" corresponds to the first period information. Therefore, the description of the timestamp "59:59" can be read as the first period information. The receiving unit 201 further receives the first period information from the user PC 30.
The inverse conversion function selection unit 208 selects an inverse conversion function f according to the first conversion period based on the first period information.<sup>-1</sup>Select the inverse transformation function f<sup>-1</sup>The inverse transformation function f is calculated based on the first period information, not on the time of selection.<sup>-1</sup>The inverse transformation function selection unit 208 selects a plurality of inverse transformation functions f based on the first period information.<sup>-1</sup>Among them, the inverse transformation function f according to the first transformation period is<sup>-1</sup>Just select:
According to the communication system S of the second modification, the user PC 30 transmits first period information related to the first conversion period to the authentication server 20. The authentication server 20 determines an inverse conversion function f according to the first conversion period based on the first period information received from the user PC 30.<sup>-1</sup>This enhances security in multi-factor authentication. Even if TUID conversion is performed near the end of a certain time period, multi-factor authentication can be performed accurately. This eliminates the need to redo multi-factor authentication due to failure, improving user convenience. The salt server 10, authentication server 20, and user PC 30 also do not perform unnecessary processing, reducing the processing load on these devices.
[4-3. Variation 3]
For example, assume that before a user logs in, a malicious third party steals 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 getSalt() command to a specific IP address), and the user's facial photo through a cross-site scripting attack or the like. In this case, even if the TUID is updated every time the user logs in, the third party has obtained the series of steps for accessing the salt server 10 and the information required for authentication, so there is a risk that impersonation may be possible.
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 the TUID and logs in, the transmission unit 304 of the user PC 30 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 transmission unit 304 also transmits a facial photograph of the user.
The process execution unit 205 of the authentication server 20 executes the authentication process based on the TUID acquired by the first inverse conversion and the hash value. Since the communication system S described in the first embodiment and the like uses not only TUID authentication but also face authentication, the process execution unit 205 executes the authentication process based on the TUID, facial feature amount, and hash value. Therefore, the authentication process of the third modification is three-factor authentication. The authentication using the TUID and facial feature amount is as described in the first embodiment and the like. The process execution unit 205 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, the authentication using the hash value is successful.
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.
According to the communication system S of the modified example 3, 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, and therefore security is enhanced.
[4-4. Variation 4]
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.
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 a first conversion on the original data, which is the e-mail, based on a first salt corresponding to a first period to generate first converted data. The first converted data is the converted e-mail. The first device transmits the first converted data, which is the converted e-mail, to the second device. Upon receiving the first converted data, the second device performs a first reverse conversion based on the first salt to obtain the original data, which is the e-mail. The method of obtaining the first salt is as described in the first to third embodiments and the first to third modifications.
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 a first conversion on the original data, which is the file to be uploaded, based on a first salt corresponding to a first period, to generate first converted data. The first converted data is the converted file. The first device transmits the first converted data, which is the converted file, to the second device. Upon receiving the first converted data, the second device performs a first inverse conversion based on the first salt to obtain the file, which is the original data. The method of obtaining the salt is as described in the first to third embodiments and modifications 1 to 3.
The same is true when the communication system S is applied to other situations, and the first device only needs to perform a first conversion on the original data according to the first period. The second device only needs to perform a first inverse conversion on the first converted data according to the first period. The communication system S of the fourth modification example enhances the security of communication in various situations.
[4-5. Other variations]
For example, the first to third embodiments may be combined. The above modified examples may be combined.
For example, the processing of Modification 1 or Modification 2 may be performed only near the end of a certain time period. 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.
11 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP2006340296A | Cites | Japan |
| JP2007295366A | Cites | Japan |
| JP2689383B1 | Cites | Japan |
| WO2018037453A1 | Cites | World Intellectual Property Organization (WIPO) |
11 members in 5 offices
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 2022577694 | Japan | A | |
| 2022008319 | Japan | W |
Members11
| Document | Office | Kind | |
|---|---|---|---|
| JPWO2023162232A1 | Japan | A1 | |
| WO2023162232A1 | World Intellectual Property Organization (WIPO) | A1 | |
| TW202337168A | Taiwan Province of China | A | |
| JP7358659B1 | Japan | B1 | |
| EP4262142A1 | European Patent Office (EPO) | A1 | |
| EP4262142A4 | European Patent Office (EPO) | A4 | |
| JP2023165912A | Japan | A | |
| US2024250935A1 | United States of America | A1 | |
| TWI853408B | Taiwan Province of China | B | |
| JP7603764B2This record | Japan | B2 | |
| US12388800B2 | United States of America | B2 |
9 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 7603764
- Application
- 166238
Titles2
- Japanese
- 第2装置、通信システム、通信方法、及びプログラム
- English
- Second device, communication system, communication method, and program
Classification
- CPC, 5
- H04L9/3297
- H04L63/0428
- H04L9/16
- H04L9/3271
- H04L9/30
- IPC, 1
- H04L9 16
