Communication system, communication method, and program
Abstract
The communication system (S) includes a first device (10) and a second device (20). The conversion unit (303) of the first device (10) performs a first conversion on the original data according to a first period to which the first time point at which the original data is converted belongs, and generates first converted data. . The transmitter (304) transmits the first converted data to the second device (20). The receiving unit (201) of the second device (20) receives the first converted data from the first device (10). The inverse transform unit (204) performs a first inverse transform on the first transformed data according to the first period to obtain original data.

Term
15.4 yearsleft in the term
Expires 28 February 2042.
- Priority and filed
- Granted
- Today
- Expires
20 claims: 15 independent, 5 dependent
- 1第1装置及び第2装置を含む通信システムであって、前記第1装置は、元データを変換するための変換情報であって、前記元データが変換される第1時点が属する第1期間の日及び時間帯に応じた第1変換情報を取得する変換情報取得部と、前記第1変換情報に基づいて、前記元データを変換することによって第1変換を行って、第1変換データを生成する変換部と、前記第2装置に対し、前記第1期間の分及び秒に関する第1期間情報と、前記第1変換データと、を送信する送信部と、を含み、前記第2装置は、前記第1装置から、前記第1期間情報と、前記第1変換データと、を受信する受信部と、前記第1期間情報に基づいて、前記第1変換データを逆変換するための逆変換情報であって、前記第1期間の日及び時間帯に応じた第1逆変換情報を取得する逆変換情報取得部と、前記第1逆変換情報に基づいて、前記第1変換データを逆変換することによって第1逆変換を行って、前記元データを取得する逆変換部と、を含む通信システム。
- 2前記変換部は、前記第1期間に属し、かつ、前記第1時点とは異なる第2時点に前記元データが変換される場合に、前記元データに対し、前記第1変換を行って、前記第1変換データを生成し、前記変換部は、前記第1期間とは異なる第2期間に属し、かつ、前記第1時点及び前記第2時点とは異なる第3時点に前記元データが変換される場合に、前記元データに対し、前記第2期間に応じた第2変換を行って、第2変換データを生成し、前記逆変換部は、前記第1変換データに対し、前記第1逆変換を行って、前記元データを取得し、前記逆変換部は、前記第2変換データに対し、前記第2期間に応じた第2逆変換を行って、前記元データを取得する、請求項 1に 記載の通信システム。
- 3前記第1期間は、日及び時間帯の組み合わせで示され、前記変換情報取得部は、前記第1期間が示す日及び時間帯の組み合わせに応じた前記第1変換情報を取得し、前記逆変換情報取得部は、前記第1期間が示す日及び時間帯の組み合わせに応じた前記第1逆変換情報を取得する、請求項1 又は2 に記載の通信システム。
- 4前記通信システムは、前記第1期間と、前記第1変換情報と、を関連付けて管理する第3装置を更に含み、前記第3装置は、前記第1装置から前記第1変換情報の取得要求を受け付けた場合に、前記第1装置に対し、前記第1期間に応じた前記第1変換情報を送信し、前記送信部は、前記第2装置に対し、前記第3装置から受信した前記第1変換情報に応じた前記第1期間情報を送信する、請求項1 ~3の何れか に記載の通信システム。
- 5前記通信システムは、複数の期間の各々と、前記逆変換情報と、を関連付けて管理する第3装置を更に含み、 前記第2装置は、前記第3装置に対し、前記逆変換情報を要求する逆変換情報要求部を更に含み、 前記第3装置は、前記第2装置に対し、前記第2装置からの要求を受け付けた場合の時点が属する期間に応じた前記逆変換情報を送信する送信部を更に含み、 前記第3装置の前記送信部は、前記第2装置からの要求を受け付けた時点が前記第1期間よりも後の第2期間である場合に、前記第2装置に対し、前記第1期間に応じた前記第1逆変換情報と、前記第2期間に応じた第2逆変換情報と、を含む複数の前記逆変換情報を送信し、 前記逆変換情報取得部は、前記第1期間情報に基づいて、前記複数の逆変換情報の中から前記第1逆変換情報を選択する、 請求項1~4の何れかに記載の通信システム。
- 6前記変換情報取得部は、前記第1期間と、前記元データの一部分と、に応じた前記第1変換情報を取得し、前記第1変換は、前記第1期間及び前記一部分に応じた変換であり、前記送信部は、前記第2装置に対し、未変換の前記一部分を更に送信し、前記逆変換情報取得部は、前記第1期間と、前記未変換の一部分と、に応じた前記逆変換情報を取得し、前記第1逆変換は、前記第1期間と、前記未変換の一部分と、に応じた逆変換である、請求項 1に 記載の通信システム。
- 7前記変換部は、前記第1変換情報に基づいて、前記元データのうち、前記一部分以外の残り部分を変換することによって、前記第1変換データを生成し、前記逆変換部は、前記逆変換情報に基づいて、前記第1変換データを逆変換して前記残り部分を取得し、当該残り部分と、前記未変換の一部分と、に基づいて、前記元データを取得する、請求項 6 に記載の通信システム。
- 8前記通信システムは、複数の期間の各々と、前記変換情報及び前記逆変換情報と、が関連付けられたデータベースを記憶するデータ記憶部を更に含み、前記変換情報取得部は、前記データベースにおいて、前記第1期間に関連付けられた前記第1変換情報を取得し、前記逆変換情報取得部は、前記データベースにおいて、前記第1期間に関連付けられた前記第1逆変換情報を取得する、請求項 1に 記載の通信システム。
- 9前記通信システムは、前記データベースを更新する更新部を更に含む、請求項 8 に記載の通信システム。
- 10前記通信システムは、複数の期間の各々と、前記変換情報及び前記逆変換情報と、を関連付けて管理する第3装置を更に含み、前記第1装置は、前記第3装置に対し、前記変換情報を要求する変換情報要求部を更に含み、前記第1時点は、前記第3装置が前記第1装置からの要求を受け付けた場合の時点であり、前記第3装置は、前記第1装置に対し、前記第1変換情報を送信する送信部を更に含み、前記変換情報取得部は、前記第3装置から、前記第1変換情報を取得し、前記第2装置は、前記第3装置に対し、前記逆変換情報を要求する逆変換情報要求部を更に含み、前記第3装置は、前記第1期間に前記第2装置からの要求を受け付けた場合に、前記第2装置に対し、前記第1逆変換情報を送信し、前記逆変換情報取得部は、前記第3装置から、前記第1逆変換情報を取得する、請求項 1に 記載の通信システム。
- 11前記変換情報要求部は、前記第3装置に対し、前記変換情報の取得ルールに関する情報を含まない要求を送信し、前記逆変換情報要求部は、前記第3装置に対し、前記逆変換情報の取得ルールに関する情報を含まない要求を送信する、請求項1 0 に記載の通信システム。
- 12前記第1装置は、複数の変換方法の中から、前記第1期間に応じた第1変換方法を選択する変換方法選択部を更に含み、前記変換部は、前記第1変換方法に基づいて、前記元データを変換することによって、前記第1変換を行い、前記第2装置は、複数の逆変換方法の中から、前記第1期間に応じた第1逆変換方法を選択する逆変換方法選択部を更に含み、前記逆変換部は、前記第1逆変換方法に基づいて、前記元データを逆変換することによって、前記第1逆変換を行う、請求項1~1 1 の何れかに記載の通信システム。
- 13前記第1期間は、時間帯で示され、前記変換方法選択部は、前記第1期間が示す時間帯に応じた前記第1変換方法を選択し、前記逆変換方法選択部は、前記第1期間が示す時間帯に応じた前記第1逆変換方法を選択する、請求項 12 に記載の通信システム。
- 14前記送信部は、前記第2装置に対し、前記第1期間に関する第1期間情報を更に送信し、 前記受信部は、前記第1装置から、前記第1期間情報を更に受信し、 前記逆変換方法選択部は、前記第1期間情報に基づいて、前記第1期間に応じた前記逆変換方法を選択する、 請求項12又は13に記載の通信システム。
- 15前記元データは、前記第1装置のユーザに関する認証データであり、前記変換部は、前記認証データに対し、前記第1変換を行って、前記第1変換データを生成し、前記逆変換部は、前記第1変換データに対し、前記第1逆変換を行って、前記認証データを取得し、前記第2装置は、前記第1逆変換により取得された前記認証データに基づいて、前記ユーザに関する認証処理を実行する処理実行部と、前記認証処理が成功した場合に、新たな前記認証データを生成する生成部と、を更に含む、請求項1~1 4 の何れかに記載の通信システム。
- 16前記元データは、前記第1装置のユーザに関する認証データであり、 前記変換部は、前記認証データに対し、前記第1変換を行って、前記第1変換データを生成し、 前記送信部は、前記第1変換データと、前記第1装置に関する複数の情報に基づくハッシュ値と、を送信し、 前記逆変換部は、前記第1変換データに対し、前記第1逆変換を行って、前記認証データを取得し、 前記第2装置は、前記第1逆変換により取得された前記認証データと、前記ハッシュ値と、に基づいて、前記ユーザに関する認証処理を実行する処理実行部を更に含む、 請求項1~14の何れかに記載の通信システム。
- 17前記処理実行部は、前記第1装置から受信した前記ハッシュ値と、予めデータベースに格納されたハッシュ値と、に基づいて、前記認証処理を実行する、 請求項16に記載の通信システム。
- 18第1装置及び第2装置の間の通信方法であって、前記第1装置は、元データを変換するための変換情報であって、前記元データが変換される第1時点が属する第1期間の日及び時間帯に応じた第1変換情報を取得する変換情報取得ステップと、前記第1変換情報に基づいて、前記元データを変換することによって第1変換を行って、第1変換データを生成する変換ステップと、前記第2装置に対し、前記第1期間の分及び秒に関する第1期間情報と、前記第1変換データと、を送信する送信ステップと、を実行し、前記第2装置は、前記第1装置から、前記第1期間情報と、前記第1変換データと、を受信する受信ステップと、前記第1期間情報に基づいて、前記第1変換データを逆変換するための逆変換情報であって、前記第1期間の日及び時間帯に応じた第1逆変換情報を取得する逆変換情報取得ステップと、前記第1逆変換情報に基づいて、前記第1変換データを逆変換することによって第1逆変換を行って、前記元データを取得する逆変換ステップと、を実行する通信方法。
- 19第2装置と通信可能な第1装置を、元データを変換するための変換情報であって、前記元データが変換される第1時点が属する第1期間の日及び時間帯に応じた第1変換情報を取得する変換情報取得部、前記第1変換情報に基づいて、前記元データを変換することによって第1変換を行って、第1変換データを生成する変換部、前記第2装置に対し、前記第1期間の分及び秒に関する第1期間情報と、前記第1変換データと、を送信する送信部、として機能させるためのプログラム。
- 20第1装置と通信可能な第2装置を、前記第1装置から、元データに対し、前記元データを変換するための変換情報であって、前記元データが変換される第1時点が属する第1期間の日及び時間帯に応じた第1変換情報に基づいて第1変換が行われた第1変換データと、前記第1期間の分及び秒に関する第1期間情報と、を受信する受信部、前記第1期間情報に基づいて、前記第1変換データを逆変換するための逆変換情報であって、前記第1期間の日及び時間帯に応じた第1逆変換情報を取得する逆変換情報取得部、前記第1逆変換情報に基づいて、前記第1変換データを逆変換することによって第1逆変換を行って、前記元データを取得する逆変換部、としてコンピュータを機能させるためのプログラム。
Independent claims20
214 paragraphs, as filed
The present disclosure relates to a communication system, a communication method, and a program.
2. Description of the Related Art Conventionally, in the communication field, techniques for converting original data so that the contents of the original data are not known to third parties are known. For example, Patent Document 1 describes a technology that generates user parameters based on a user ID input by a user, and converts biometric data, which is an example of original data, based on the generated user parameters. There is. For example, Patent Document 2 describes a technique for converting a salt, which is an example of original data, using a public key cryptosystem. For example, Patent Document 3 describes a technique called challenge and response, which is a type of public key cryptography.
<p><patcit num="1"><text>Patent No. 4966765</text></patcit><patcit num="2"><text>Patent No. 6866803</text></patcit><patcit num="3"><text>Re-publication No. 2020-85141</text></patcit></p>
<p>However, in the technique of Patent Document 1, since user parameters are transmitted over the 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 a third party to impersonate the user using the illegally obtained user parameters and biometric data. Since user parameters are generated based on a user ID that, in principle, does not change once issued, a third party can use the user parameters once obtained to impersonate the user over a long period of time.</p><p>The public key cryptosystem of Patent Documents 2-3 is an encryption system that uses a pair of a public key that is disclosed to a third party and a private key that is not disclosed to a third party. However, since the private key is information that does not change in principle, if a third party somehow obtains the private key, the third party will be able to use the private key once obtained to commit fraud over a long period of time. The techniques disclosed in Patent Documents 1 to 3 allow fraud to be carried out over a long period of time, making it impossible to sufficiently enhance communication security.</p><p>One of the objectives of the present disclosure is to increase security in communications.</p>
<p>A communication system according to an aspect of the present disclosure is a communication system including a first device and a second device, wherein the first device converts original data into a first point in time at which the original data is converted. The second device includes a converting unit that performs a first conversion according to one period to generate first converted data, and a transmitting unit that transmits the first converted data to the second device. , a receiving unit that receives the first converted data from the first device, and an inverse conversion that performs a first inverse conversion on the first converted data according to the first period to obtain the original data. including.</p>
<p>According to the present disclosure, security in communication is increased.</p>
<figref num="1">FIG. 1 is a diagram showing an example of the overall configuration of a communication system.</figref><figref num="2">FIG. 3 is a diagram showing an example of the flow of multi-factor authentication in the first embodiment.</figref><figref num="3">FIG. 2 is a functional block diagram showing an example of functions realized by the communication system of the first embodiment.</figref><figref num="4">FIG. 3 is a diagram showing an example of a salt database.</figref><figref num="5">FIG. 3 is a diagram showing an example of a user database.</figref><figref num="6">FIG. 3 is a diagram illustrating an example of processing executed in the communication system of the first embodiment.</figref><figref num="7">FIG. 3 is a diagram illustrating an example of processing executed in the communication system of the first embodiment.</figref><figref num="8">FIG. 7 is a diagram showing an example of the flow of multi-factor authentication in the second embodiment.</figref><figref num="9">FIG. 7 is a diagram showing an example of the flow of multi-factor authentication in a third embodiment.</figref><figref num="10">FIG. 7 is a diagram showing an example of functional blocks implemented in a communication system according to a third embodiment.</figref><figref num="11">7 is a diagram showing an example of the flow of multi-factor authentication in Modification 1. FIG.</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, an example is given in which the communication system is applied to a scene where user authentication is performed, but the communication system can be applied to any scene. Examples of application to other scenes will be explained in Modified Example 4 below.
[1-1. Overall configuration of 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 may include at least one computer, and is not limited to the example shown in FIG. 1.
Salt server 10 is a server computer. Control unit 11 includes at least one processor. The storage unit 12 includes volatile memory such as RAM and nonvolatile 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.
Salt server 10 is an example of a third device. Therefore, the portion described as salt server 10 can be read as the third device. The third device may be any device and is not limited to a server computer such as salt server 10. For example, the third device may be a personal computer, a tablet terminal, or a smartphone.
The salt server 10 manages salt in cryptographic theory. Salt is information for converting information to be converted. The salt is information that is input to the conversion function together with the information to be converted. Transformation is sometimes called encryption or hashing. The transformation is reversible. The information after conversion can be returned to the information before conversion by performing inverse conversion. Managing salts means remembering salts.
As the salt itself, any known salt can be used. For example, the salt is a random value. The salt may be in any form, such as numbers, letters, other symbols, or combinations thereof. The salt server 10 may generate the salt, or the generation of the salt itself may be performed by a device other than the salt server 10.
Authentication server 20 is a server computer. The physical configurations of the control section 21, the storage section 22, and the communication section 23 may be the same as those of the control section 11, the storage section 12, and the communication section 13, respectively.
Authentication server 20 is an example of a second device. Therefore, the part described as authentication server 20 can be read as second device. The second device may be any device and is not limited to a server computer such as authentication server 20. For example, the second device may be a personal computer, a tablet terminal, or a smartphone.
User PC30 is a user's personal computer. The physical configurations of the control section 31, the storage section 32, and the communication section 33 may be the same as those of the control section 11, the storage section 12, and the communication section 13, respectively. The operation unit 34 is an input device such as a mouse, a keyboard, or a touch panel. The display section 35 is a liquid crystal display or an organic EL display. Photographing section 36 includes at least one camera.
User PC 30 is an example of a first device. Therefore, the portion where user PC 30 is written can be read as first device. The first device may be any device and is not limited to a personal computer such as 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.
Note that the programs stored in the storage units 12, 22, and 32 may be supplied via the network N. For example, at least one of a reading section for reading a computer-readable information storage medium (for example, an optical disk drive or a memory card slot) and an input/output section for inputting and outputting data with an external device (for example, a USB port). A program stored on an information storage medium may be supplied via the computer.
[1-2. Overview of communication system in first embodiment]
For example, in the communication system S, multi-factor authentication is performed to confirm the authenticity of the 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 be used. The element itself can be of various types, and may be, for example, a biological element, a possession element, or a knowledge element.
Multi-factor authentication uses authentication data according to factors. Various types of authentication data can be used. For example, in biometric authentication, biometric data such as a face photo, facial feature amounts, a fingerprint photo, a fingerprint feature amount, a vein scan image, or a vein feature amount 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 authentication data. In knowledge authentication, knowledge information such as a user ID, password, PIN, or secret question corresponds to authentication data.
In the first embodiment, a case where multi-factor authentication is performed to log into 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 in other situations, such as when applying for online services, when making electronic payments, or when performing administrative procedures online. Various services can be applied to the online service itself. For example, online services may include financial services, communication services, payment services, electronic commerce services, or SNS.
For example, when a user registers to use an online service, a user ID and password for logging into the online service are issued. The user accesses the online service website using the user PC 30 and enters the user ID and password. The authentication server 20 verifies the validity of the user based on the user ID and password input by the user. Once the user's legitimacy is verified, the user can log into the online service.
If you are required to enter your user ID and password every time you log in, it will be very time-consuming. For this reason, multi-factor authentication that combines face authentication and password authentication may reduce the effort required to enter user IDs. However, even in this case, it is necessary to input the password. If a user is logged in only by face authentication without generating any input 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 false authentication increases. There is also the possibility that a third party who somehow obtains a photograph of the user's face may impersonate the user.
Therefore, in the first embodiment, in order to prevent input from the operation unit 34 and ensure security, when the user logs into the online service, the authentication server 20 issues a temporary user ID. Hereinafter, this temporary user ID will be referred to as TUID (Temporary User ID). TUID is information that can identify a user. A TUID becomes invalid when certain invalidation conditions are met. In the first embodiment, a case is exemplified in which the invalid condition is that the user logs in to an online service, but the invalid condition may be any condition. For example, the invalidation condition may be that a predetermined expiration date has passed, that logins have occurred a certain number of times, or that the user has performed a predetermined operation.
The TUID issued by the authentication server 20 is recorded on the user PC 30. In the first embodiment, a case will be described in which the TUID is recorded as a browser cookie, but the TUID may be recorded as information other than cookies. The TUID may be displayed on the display unit 35, but as a general rule, it should not be visible to the user. When logging in from the second time onward, TUID authentication using TUID is performed in addition to facial recognition. TUID authentication is a type of possession authentication because TUID authentication will not be successful unless the user PC 30 has a TUID recorded. Multi-factor authentication that combines face authentication and TUID authentication would not require input from the operation unit 34 and would ensure a certain level of security.
However, if the same TUID is used for a long period of time, a valid TUID may be stolen by a malicious third party. For example, a third party could steal a cookie through a replay attack, and the TUID contained in the cookie could also be stolen. If a third party were to somehow obtain not only the TUID but also the user's facial photo, it would be possible for them to impersonate the user. Therefore, it is possible to disable TUID after a certain period of time.
However, if the TUID is immediately invalidated, users who do not log in very often will be required to enter their user ID and password every time, reducing user convenience. Therefore, in the first embodiment, a salt is used to convert the TUID in order to improve user convenience and prevent the TUID from being stolen by a third party. However, if the same salt is used for a long period of time, there is a possibility that the salt itself may be stolen by a third party, so the salt is used according to the day and time of day 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 the user logs into the online service, the user PC 30 sends a salt request to the salt server 10 to obtain the salt. In the example in Figure 2, a command such as getSalt() is included in the salt request. This command does not include conditions regarding the salt, so even if a malicious third party intercepts the salt request, it would be impossible to determine the conditions under which the salt was generated.
When the salt server 10 receives the salt request, it refers to the salt database DB1 and obtains the salt according 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 is 31 days and the 24 hours of a day are divided into hourly time zones, then in the example in Figure 2, 31×24=744 salts are stored in the salt database DB1. If the time when the salt server 10 retrieves the salt from the salt database DB1 is "December 2, 2021 01:25:34", the salt server 10 will respond to "2nd" and "01:00". Obtain the salt "8414" and send it to the user PC30.
Upon receiving the salt "8414" from the salt server 10, the user PC 30 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 will be the sum of these values, ``320870''. The user PC 30 transmits to the authentication server 20 an authentication request including the user's face photo generated by the photographing unit 36 and the converted TUID "320870".
Upon receiving the authentication request, the authentication server 20 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. Therefore, when a salt request is made from the authentication server 20 to the salt server 10, the salt condition is unknown, such as getSalt(). By making the format of salt requests common, the API of Salt Server 10 can also be made common.
When the salt server 10 receives a salt request from the authentication server 20, it refers to the salt database DB1 and obtains the salt according to the current day and time zone. If the time point when the salt server 10 retrieves the salt from the salt database DB1 is "December 2, 2021, 01:25:35", the salt server 10 will respond to "2nd" and "01:00". Send the salt "8414" to the authentication server 20. This salt "8414" is the same as that sent to the user PC 30.
When the authentication server 20 receives the salt "8414" from the salt server 10, the authentication server 20 receives the salt "8414" and the inverse transformation function f.<sup>-1</sup>Based on and, the converted TUID "320870" received from the user PC is inversely converted. In the example in Figure 2, the inverse transformation 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" through reverse conversion.
Upon acquiring the TUID "312456", the authentication server 20 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 the existence of TUID "312456" corresponds to TUID authentication. If the TUID "312456" is not stored in the user database DB2, an error will occur at that point and the user will not be able to log in.
When the authentication server 20 confirms that the TUID "312456" exists in the user database DB2, it acquires the facial features associated with the TUID "312456" and stored in the user database DB2. The authentication server 20 executes face authentication based on the obtained facial feature amount and the facial feature amount calculated from the facial photo received from the user PC 30. When the face 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 enters a state where it is logged into the online service.
Furthermore, if a malicious third party steals the converted TUID "320870" and the user's facial photo through a cross-site scripting (XSS) attack after the user logs in, the user's facial photo will be stolen until the salt is switched. , there is a risk that spoofing by a third party will be possible. 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. Assuming that the new TUID is "417632", the authentication server 20 only needs to transmit the 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 even if a third party attempts a cross-site scripting (XSS) attack as described above, authentication will not 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 for inversely converting the new TUID after conversion.<sup>-1</sup>Assume that you remember. In this inverse conversion as well, the salt "8414" that has already been received from the salt server 10 may be used.
As described above, the communication system S of the first embodiment converts the TUID and inversely converts the converted TUID based on the salt depending on the combination of the day and time zone when the user logs in. do. This prevents a third party from easily obtaining the TUID because the TUID is not sent as is over the network N. 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, which improves the security of communications. It's starting to increase. Hereinafter, details of the communication system S of the first embodiment will be explained.
[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 by the communication system S of the first embodiment.
[1-3-1.Functions realized in the salt server]
The data storage section 100 is realized mainly by the storage section 12. The salt generating section 101, the receiving section 102, the transmitting section 103, and the updating section 104 are realized mainly by the control section 11.
[Data storage]
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 periods is associated with a salt (an example of conversion information and inverse conversion information). The salt server 10 manages each of the plurality of periods in association with 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 using a database called by a name other than salt database DB1.
FIG. 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 day and time zone. That is, in the salt database DB1, combinations of days and time zones are associated with salts. The salt stored in the salt database DB1 may be updated at predetermined timing.
In the example in Figure 4, a case will be explained in which the salt used in the past day and time and the salt scheduled to be used in the future day and time are also stored. Only those salts may be stored in the salt database DB1. For example, if the current time is "December 2, 2021 01:25:34", only the salts of "2nd" and "01 o'clock" may be stored in the salt database DB1. In this case, when it comes to "December 2, 2021 02:00:00", only the salts of "2nd" and "02:00" are stored in the salt database DB1.
Note that 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 a salt. The data storage unit 100 may store data regarding an API 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 use a common API so that salt requests of the same format can be accepted from the authentication server 20 and the user PC 30. The API for
[Salt generation part]
Salt generation section 101 generates salt based on a predetermined algorithm. For example, the salt generation unit 101 generates a salt to have a random value. Various known methods can be used to generate random values. For example, a method may use a timestamp at the time of salt generation, or a method may use data other than a timestamp. The salt generation unit 101 stores the generated salt in the salt database DB1.
In the first embodiment, the salt generation unit 101 generates a salt for each combination of future day and time zone. 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 updating unit 104, which will be described later. This timing may be any timing, 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 will be exemplified in which the same salt is used for TUID conversion and inverse conversion of TUID after conversion. Therefore, the salt is an example of transformation information and also an example of inverse transformation information. The part described as salt can be read as conversion information. The part described as salt can also be read as reverse conversion information. Conversion information is a cryptographic key in cryptographic theory. Inverse transformation information is a decryption key in cryptographic theory. 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 cryptographic theory. The conversion information and inverse conversion information may be called by names other than keys; for example, a password used in encrypting a file may correspond to the conversion information and inverse conversion information.
The transformation information and the inverse transformation 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. If the conversion information and inverse conversion information are different from each other, both the conversion information and the inverse conversion information are stored in the salt database DB1. The conversion information of both of these is sent to the user PC 30, and the inverse conversion information is sent to the authentication server 20. If the conversion information and inverse conversion information are to be created according to the combination of day and time zone as in the first embodiment, the salt database DB1 contains conversion information and inverse conversion information for each combination of day and time zone. combinations are stored.
[Receiving section]
The receiving unit 102 receives salt requests from each of the authentication server 20 and user PC 30. A salt request is information in a predetermined format sent to request salt. In FIG. 2, a salt request including a command such as getSalt() is taken as an example, but the salt request may be any information indicating that salt is requested. In the first embodiment, a case will be described in which the salt request from the authentication server 20 and the salt request from the user PC 30 have the same format, but these formats may be different from each other. The salt request is an example of a request for transformation information, and is also an example of a request for inverse transformation information. Therefore, the portion describing the salt request can be read as a request for conversion information or a request for inverse conversion information. These requests can be called any name other than salt requests.
[Transmitter]
The transmitter 103 transmits a salt corresponding to inverse transformation information to the authentication server 20. The transmitter 103 transmits the salt corresponding to the conversion information to the user PC 30. In the first embodiment, the transmitting unit 103 transmits to each of the authentication server 20 and the user PC 30 a salt corresponding to the day and time period to which the salt is acquired. The salt acquisition time may be any time after the salt request is received until the salt is sent. The transmitter 103 refers to the salt database DB1 and identifies the combination of day and time zone to which the salt acquisition time belongs. The transmitter 103 transmits the salt associated with the identified combination to each of the authentication server 20 and the user PC 30.
For example, assume that the salt server 10 receives a salt request from the authentication server 20 during a first period to which a certain first point in time belongs (in the example of FIG. 2, around 01:00 on the 2nd). The first point in time is the point in time when the salt server 10 receives a salt request from the user PC 30. The transmitter 103 transmits the first salt to the user PC 30 when receiving a salt request from the user PC 30 during the first period. The first salt is a salt according to the first period. In the example in Figure 2, the first period is "01 o'clock" on "2nd", so the first salt is the salt "8414" associated with "01 o'clock" on "2nd" in salt database DB1. It is. Hereinafter, when the first salt corresponding to the first period and other salts corresponding to other periods are not distinguished, they will simply be described as salts.
Transmitting section 103 transmits a first salt to authentication server 20 when receiving a salt request from authentication server 20 during the first period. That is, when receiving a salt request from the authentication server 20 and a salt request from the user PC 30 in the same first period, the transmitter 103 transmits the same first salt to each of the authentication server 20 and the user PC 30. Send. 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 sends the request to each of the authentication server 20 and the user PC 30. Suppose that different salts are sent. In this case, the salt used for TUID conversion and the salt used for TUID inverse conversion do not correspond, so the authentication process fails without normal inverse conversion, and the sequence of authentication processes has to be restarted. It will be done.
Note that although FIG. 3 shows only one transmitter 103, transmitting the salt to the user PC 30 and transmitting the salt to the authentication server 20 can be regarded as separate functions. Therefore, the transmitting unit 103 transmits the salt to the user PC 30 when the salt request from the user PC 30 is accepted, and the first transmitting unit 103A transmits the salt to the user PC 30 when the salt request from the authentication server 20 is accepted. , and a second transmitter 103B that transmits the salt to the authentication server 20. If the procedure for transmitting the salt to the user PC 30 and the procedure for transmitting the salt to the authentication server 20 are different, the first transmitter 103A transmits the salt to the user PC 30 in accordance with the procedure for transmitting the salt to the user PC 30. Just send it. The second transmitter 103B may transmit the salt to the authentication server 20 in accordance with the procedure for transmitting the salt to the authentication server 20.
[Update section]
The update unit 104 updates the salt database DB1. The update unit 104 determines whether a predetermined update condition is satisfied or not, and updates the salt database DB1 when the update condition is satisfied. The update conditions are conditions for updating the salt database DB1. Any update conditions can be set. In the first embodiment , an example is given in which the update condition is that midnight arrives every day (the date changes), but the update conditions are that the administrator performs a predetermined operation, and that the authentication process is performed in a predetermined manner. Other conditions such as being executed a number of times or more, or obtaining a salt a predetermined number of times or more may be used.
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 conditions (for example, timestamp) differ each time the salt database DB1 is updated. Therefore, each time the salt database DB1 is updated, a salt with a different value is generated. In the data storage example of FIG. 4, when midnight arrives every day, the salt database DB1 is updated so that salts from 00:00 to 23:00 on that day are generated.
[1-3-2.Functions realized by the authentication server]
The data storage section 200 is realized mainly by the storage section 22. A receiving section 201, a salt requesting section 202, a salt obtaining section 203, an inverse conversion section 204, a processing execution section 205, a TUID generating section 206, and a transmitting section 207 are implemented.
[Data storage]
Data storage unit 200 stores data necessary for communication with 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 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 that stores information regarding users. For example, the user database DB2 stores a user ID, password, name, TUID, facial photo, and facial feature amount. The information stored in the user database DB2 may be of any type and is not limited to the example in FIG. 5. For example, a session ID for maintaining a session with the user PC 30, a user's past login history, or a user's usage history of online services may be stored in the user database DB2.
A facial photograph is an example of biometric data (biometric information). TUID is an example of authentication data (authentication information) different from biometric data. Therefore, the portions that describe face photographs can be read as biometric data. Where TUID is explained, it can be read as authentication data that is different from biometric data. The combination of biometric data and authentication data different from the biometric data may be any combination. 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 types of data; for example, facial feature amounts may correspond to the biometric data. Information called a template into which facial feature amounts are converted may correspond to 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 biometric data is information used in multi-factor authentication together with 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 biometric data.
Note that the data storage unit 200 can store any data other than the user database DB2. For example, the data storage unit 200 stores the inverse transformation function f<sup>-1</sup>may be memorized. For example, the data storage unit 200 may store an algorithm for generating a TUID.
[Receiving section]
The receiving unit 201 receives the converted TUID from the user PC 30. The receiving unit 201 can receive a converted TUID converted with a salt corresponding to an arbitrary period. The converted TUID converted using the salt corresponding to the first period described above is an example of first converted data. Therefore, the part that describes the converted TUID converted with the salt according to the first period can be read as the first converted data. The first converted data is data obtained by performing the first conversion according to the first period on the TUID, which is an example of the original data. Original data is data to be converted. Original data is data before conversion. The original data corresponds to plaintext in cryptography theory. In the first embodiment, the original data is authentication data regarding the user of the user PC 30. Original data is data before conversion, so it is sometimes called raw data.
In the first embodiment, the receiving unit 201 receives a converted TUID and a face photo from the user PC 30. Receiving a face photograph means receiving image data of an image in which a face is photographed. The face photo may be a still image or an individual frame included in a video. In the first embodiment, a case will be exemplified in which the TUID after conversion and a face photo are included in the authentication request. Therefore, by receiving an authentication request from the user PC 30, the receiving unit 201 receives the converted TUID and the facial photo. The authentication request is a request to perform multi-factor authentication. The authentication request may be made by transmitting information in a predetermined format. The authentication request may also include other information. For example, the authentication request may include information that can identify the user PC 30, such as the IP address of the user PC 30.
[Salt request part]
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 that does not include information regarding salt acquisition rules to the salt server 10. For example, when a salt corresponding to a combination of day and time zone is acquired, the acquisition rule is a combination of day and time zone. Since the salt request does not include date and time zone information, it does not include information regarding acquisition rules.
Information regarding the acquisition rule is not included in the salt request, even when other acquisition rules are adopted. For example, if you want to use a different salt for each day without considering the time zone, the acquisition rule will be only 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 you want to use a different salt for each time zone without considering the day, the only acquisition rule is the time zone. Since the salt request does not include information regarding the time zone, it does not include information regarding the acquisition rule.
Note that the salt request may include a salt acquisition rule. For example, seed information for generating a salt may be included in the salt request. In this case, since the salts will not be the same unless the seeds are the same, it is assumed that the seeds that generated the salts are shared between the authentication server 20 and the user PC 30. For example, as in the second embodiment described below, 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 part]
The salt acquisition unit 203 acquires a first salt corresponding to the first period, which is a salt for inversely converting the converted TUID. This first salt is an example of first inverse transformation information. The salt acquisition unit 203 is an example of an inverse transformation information acquisition unit. Therefore, the portion describing the salt acquisition unit 203 can be read as the inverse transformation information acquisition unit. The inverse transformation information acquisition unit acquires inverse transformation information, for example a salt. If the inverse transformation information is called by a name other than salt, the inverse transformation information acquisition unit may be called by a name corresponding to this name. For example, if the reverse conversion information is called a key or password, the reverse conversion information acquisition unit acquires the key or password.
In the first embodiment, the salt server 10 manages the salt, so the salt acquisition unit 203 acquires the salt from the salt server 10. The salt may be managed by the authentication server 20 itself. In this case, the data storage unit 200 stores the salt database DB1. Furthermore, in this case, the salt generation section 101, reception section 102, transmission section 103, and update section 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 a salt corresponding to the combination of the day and time zone indicated by the first period. The combination of day and time zone is an example of the first period. Therefore, the portions that explain combinations of days and time zones can be read as the first period. The first period is the period to which the first time point in which the salt is obtained belongs. In the first embodiment, an example is given in which the first period is indicated by a combination of days and time zones, but the first period may mean only days or only time zones. .
The way the first period is divided is not limited to one hour units as in the first embodiment. The length of each individual period may be longer or shorter than one hour. The length of one period and another period may be different. Even if the first period has a meaning other than a combination of day and time zone, the salt acquisition unit 203 may acquire a salt corresponding to the first period. It is assumed that the relationship between each period and the salt is stored in the salt database DB1.
The salt acquisition unit 203 may acquire the salt corresponding to the first period. For example, the salt acquisition unit 203 acquires the 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 receives the salt request from the authentication server 20 is the second period that is later than the first period, the salt acquisition unit 203 obtains the salt according to the second period. get.
[Inverse conversion part]
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 a TUID, which is an example of original data and authentication data. The first inverse transformation is an inverse transformation according to the first transformation. The first inverse transformation is decryption in cryptography theory. If the time point at which the authentication server 20 inversely converts the converted TUID is in the second period after the first period, the inverse converter 204 converts the second converted data into a second period according to the second period. Perform inverse transformation to obtain the original data.
The inverse transformation unit 204 performs the first inverse transformation by inversely transforming the transformed TUID based on the first salt corresponding to the first period. Inverse transform function f for the first inverse transform<sup>-1</sup>is stored in the data storage unit 200. The inverse transformation unit 204 converts the converted TUID into an inverse transformation function f based on the first salt, which is an example of inverse transformation information.<sup>-1</sup>Convert inversely. In the example of FIG. 2, the inverse transformation unit 204 inversely transforms the transformed TUID by subtracting the first salt from the transformed TUID to obtain the TUID.
Note that the inverse transformation itself is performed using various inverse transformation functions f<sup>-1</sup>can be used, and is not limited to subtraction as shown in Figure 2. For example, the inverse transformation may be performed by addition, multiplication, division, matrix transformation, other calculations, or a combination thereof. In the example in Figure 2, for the sake of simplicity, the transformation function f and the inverse transformation function f<sup>-1</sup>Although these are shown as simple addition and subtraction, they are actually calculation formulas that are somewhat complex. Furthermore, inverse transformation is not limited to decryption in cryptographic theory, but may also be decompression of a compressed file. If decompression is equivalent to inverse transformation, then compression is equivalent to transformation. Compression corresponds to the conversion in the first embodiment because some conversion is performed on the file. Since decompression is a process of returning a compressed file to its original state, it corresponds to inverse conversion in the first embodiment.
[Processing execution part]
The processing execution unit 205 executes authentication processing regarding the user based on the authentication data obtained by the first inverse transformation. In the first embodiment, multi-factor authentication will be described as an example of the authentication process, but the authentication process may be one-factor authentication. For example, only TUID authentication may be performed without using face authentication. Further, the processing execution unit 205 may execute processing according to the situation in which the communication system S is applied, and the processing executed by the processing execution unit 205 is not limited to authentication processing. Processing when the communication system S is applied to other situations will be explained in a modified example below. The processing execution unit 205 may execute a predetermined process based on the original data acquired by the inverse transformation unit 204.
For example, the processing execution unit 205 executes multi-factor authentication based on the TUID inversely converted by the inverse conversion unit 204 and the face photo received by the reception unit 201. As mentioned above, various types of multi-factor authentication can be used. In the first embodiment, the processing execution unit 205 refers to the user database DB2 and obtains facial feature amounts associated with the TUID inversely transformed by the inverse transformer 204. This facial feature amount is authentication data that is the correct answer in multi-factor authentication. Among the facial feature quantities stored in the user database DB2, only the facial feature quantities associated with the TUID that has been inversely transformed by the inverse transformer 204 are to be compared. Other facial features are not subject to comparison.
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 to calculate facial feature amounts. For example, facial feature amounts may be calculated using a calculation method using a contrast filter or principal component analysis. Facial features can be expressed in any format, such as a multidimensional vector, an array, or a single numerical value. Rather than comparing facial features, facial recognition may be of the type that inputs two facial photos into a machine learning model to determine similarity.
The processing execution unit 205 determines the similarity between the facial feature amount acquired from the user database DB2 and the facial feature amount calculated from the facial photo received by the receiving unit 201. For example, when facial features are expressed as multidimensional vectors, the fact that the distance between the facial features on the vector space is less than a threshold corresponds to the fact that the features are similar. The processing execution unit 205 determines that multi-factor authentication has been successful when the facial feature amounts are similar to each other. If the facial feature amounts are not similar to each other, the processing execution unit 205 determines that multi-factor authentication has failed.
[TUID generator]
The TUID generation unit 206 generates a new TUID when the authentication process is successful. TUID generation section 206 generates a TUID based on a predetermined algorithm. The TUID generation unit 206 generates a TUID to be newly recorded in the user PC 30 when the TUID does not exist 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 in the user PC 30.
For example, the TUID generation unit 206 generates a TUID to be a random value. Various known methods can be used to generate random values. For example, a method may use a timestamp at the time of TUID generation, 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 as not to overlap with another user's TUID. The TUID generation unit 206 allows duplication with the TUID of another user who does not have a similar face, but may generate a TUID such that the TUID does not overlap with the TUID of another user who has a similar face. The TUID generation unit 206 may generate a TUID when multi-factor authentication is successful. That is, the TUID generation unit 206 may generate a TUID every time a user logs into an online service. If it is the first login, the TUID generation unit 206 generates a TUID if the user ID and password authentication is successful.
Note that 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 you want to enable the same TUID a predetermined number of times or more, rather than invalidating the TUID after just one login, the TUID generation unit 206 You may also generate a TUID. For example, if a TUID is set with an expiration date, the TUID generation unit 206 may generate the TUID when the user logs in when the expiration date approaches.
[Transmitter]
The transmitting 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 or not multi-factor authentication was successful. For example, the authentication result indicates whether or not login is permitted. In the first embodiment, a new TUID is generated at the time of login, so the new TUID is included in the authentication result.
Note that if multi-factor authentication is successful, execution of a predetermined process is permitted. In the first embodiment, logging into an online service will be described as an example of this process, but this process may be any process that is permitted on the condition that multi-factor authentication is successful. This process may be determined depending on the situation in which the communication system S is applied. For example, when the communication system S is applied to financial services, executing a transfer may correspond to a predetermined process. For example, when the communication system S is applied to a payment service, execution of payment may correspond to predetermined processing. For example, when the communication system S is applied to an electronic commerce service, purchasing a product may correspond to a predetermined process. The predetermined process may be any other process.
[1-3-3. Functions realized on user PC]
The data storage section 300 is realized mainly by the storage section 32. The salt requesting section 301, the salt acquiring section 302, the converting section 303, the transmitting section 304, and the receiving section 305 are realized mainly by the controlling section 31.
[Data storage]
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 section 36 is not used to generate a photograph of the user's face, the data storage section 300 may store image data of the photograph of the user's face. For example, if an application for online services is prepared, the data storage unit 300 may store this application.
[Salt request part]
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 regarding salt acquisition rules to the salt server 10. This point is similar to the salt request unit 202 of the authentication server 20. Other points regarding the salt request are also as described in the processing of the salt request unit 202.
In the first embodiment, the salt requesting unit 301 requests salt from the salt server 10 when the photographing unit 36 generates a facial photograph. The salt requesting unit 301 may request the salt at any timing, and is not limited to the timing at which the face photo is generated. For example, the salt requesting unit 301 requests salt when an application for an online service is launched, when a user performs a login operation, or when an access to an online service website occurs. Good too.
[Salt acquisition part]
The salt acquisition unit 302 is a salt for converting a TUID, which is an example of original data, and acquires a first salt 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 portion describing the salt acquisition unit 302 can be replaced with the conversion information acquisition unit. The conversion information acquisition unit acquires conversion information, an example of which is a 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 password, the conversion information acquisition unit acquires the key or password.
In the first embodiment, since the acquisition of the salt from the salt server 10 to the user PC 30 and the acquisition of the salt from the salt server 10 to the authentication server 20 are performed in the same procedure, the process of the salt acquisition unit 302 is This is similar to the process of the salt acquisition unit 203 of the server 20. Therefore, the same applies to acquiring the salt from the salt server 10 and acquiring the salt according to the combination of day and time zone.
In the first embodiment, the first period is indicated by a combination of day and time zone, so the salt acquisition unit 302 acquires the first salt according to the combination of day and time zone indicated by the first period. The salt acquisition unit 302 acquires the 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 the 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.
[Converter]
The conversion unit 303 generates first converted data by performing a first conversion on the TUID, which is an example of the original data and authentication data, in accordance with a first period to which the first time point to which the TUID is converted belongs. The first conversion is a conversion according to the first period. In the first embodiment, the conversion based on the first salt according to the first period corresponds to the first conversion. If the second time point is different from the first time point but belongs to the same first period as the first time point, the first conversion is performed. Therefore, when the TUID belongs to the first period and is converted to a second time point different from the first time point, the conversion unit 303 performs the first conversion on the TUID and converts the first conversion data. generate.
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 converts the TUID into a second time period. A second conversion is performed according to the period to generate second conversion data. In the first embodiment, the conversion based on the second salt corresponding to the second period corresponds to the second conversion. The transformation function f itself is the same for the first and second transformations, but the salt input to the transformation function f is the first salt for the first transformation and the first salt for the second transformation. Since it is a 2-salt, the first and second transformations are different from each other. That is, the first salt, which is an example of first conversion information used in the first conversion, and the second salt, which is an example of 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. Transformation is encryption in cryptographic theory. The conversion may be anything that involves some kind of change to the TUID. For example, inputting TUID into some function, changing part of TUID, changing all of TUID, adding some information to TUID, or deleting part of TUID is a conversion. corresponds to The inverse conversion may be any process in the opposite direction (processing to restore the TUID). As mentioned above, file compression may correspond to conversion, and file decompression may correspond to inverse conversion. In this case, compression or decompression is performed using the first salt as a password.
It is assumed that the conversion function f for conversion is stored in the data storage unit 300. The conversion unit 303 converts the TUID before conversion using a conversion function f based on a salt that is an example of conversion information. In the example of FIG. 2, the conversion unit 303 converts the TUID before conversion by adding a salt to the TUID before conversion, and obtains the TUID after conversion. The conversion itself can use various conversion functions, and is not limited to addition as shown in FIG. For example, the transformation may be performed by subtraction, multiplication, division, matrix transformation, other calculations, or a combination thereof.
[Transmitter]
The transmitter 304 transmits the converted TUID to the authentication server 20. For example, the transmitting unit 304 transmits the converted TUID and the facial photo to the authentication server 20. In the first embodiment, a case will be exemplified in which the TUID after conversion and a face photo are included in the authentication request. Therefore, the transmitting unit 304 transmits the converted TUID and the facial photo by transmitting an authentication request including the converted TUID and the facial photo to the authentication server 20. The transmitting unit 304 does not have to transmit the converted TUID and the face photo together as one data. The transmitter 304 may transmit the converted TUID and the face photo separately. Note that the face photo may not be sent as is, but may be converted based on a salt or other encryption key. 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.
[Receiving section]
Receiving section 305 receives the authentication result from authentication server 20. If the authentication result indicates success, the user logs into the online service. That is, execution of the predetermined process described above is permitted. If a new TUID is included in the authentication result, receiving section 305 records the TUID included in the authentication result in data storage section 300. The old TUID 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]
6 and 7 are diagrams illustrating an example of processing executed by the communication system S of the first embodiment. The processes in FIGS. 6 and 7 are executed by the control units 11, 21, and 31 executing programs stored in the storage units 12, 22, and 32, respectively. When the processes in FIGS. 6 and 7 are executed, it is assumed that the user's user ID and password have already been issued. It is also assumed that the salt has already been stored in the salt database DB1.
As shown in FIG. 6, the user PC 30 starts an online service application and determines whether or not the TUID exists in the storage unit 32 (S1). If it is determined that there is no TUID (S1; N), the user PC 30 accepts the user's input of the user ID and password based on the detection signal from the operation unit 34 (S2). A login process for logging into 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 sends the 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. At S7, the TUID may be recorded as part of the cookie. Thereafter, the user PC 30 executes processing for allowing the user to use the online service. When the user performs an operation to log out from the online service, a logout process for logging out from the online service is executed between the authentication server 20 and the user PC 30.
In S1, if it is determined that there is a TUID (S1; Y), the user PC 30 photographs the user's face based on the photographing unit 36 to generate a facial photograph (S8). The user PC 30 transmits a salt request to the salt server 10 (S9). When the salt server 10 receives the salt request (S10), it transmits the 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 this salt (S13).
Moving on to FIG. 7, the user PC 30 transmits an authentication request including the TUID after conversion in S13 and the face photo 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). When the salt server 10 receives the salt request (S17), it transmits a salt according to the current day and time zone to the authentication server 20 based on the salt database DB1 (S18).
Upon receiving the salt from the salt server 10 (S19), the authentication server 20 reversely converts the converted TUID included in the authentication request received in S15 based on this salt (S20). The authentication server 20 performs multi-factor authentication based on the TUID reverse-converted in S20 and the face photo included in the authentication request received in S15 (S21). In S21, the authentication server 20 acquires the facial feature amount associated with the TUID that was inversely converted in S20, based on the user database DB2. The authentication server 20 calculates facial features based on the facial photo received in S15. The authentication server 20 determines whether the degree of similarity of the acquired facial feature amounts is equal to or greater than a threshold value. Multi-factor authentication is successful if the TUID exists in the user database DB2 and the similarity of facial features is equal to or greater than the threshold.
The authentication server 20 determines whether the multi-factor authentication was successful (S22). If multi-factor authentication fails (S22;N), this process ends. In this case, input of a user ID and password may be required. If the multi-factor authentication is successful (S22; Y), the user is allowed to log in to the online service, and the process moves to S4. The TUID of the user PC 30 is updated by the processing from S4 onwards.
According to the communication system S of the first embodiment, the user PC 30 performs the first conversion on the TUID according to the first period to generate the 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 a TUID. As a result, the converted TUID is sent over the network, and the TUID is not acquired by a third party, thereby increasing security in communication. Even if a third party somehow obtains the first conversion mechanism, the period during which this mechanism can be used is limited, so the period during which fraud can be committed can be suppressed to a certain degree, increasing the security of communications. .
Furthermore, even if the first and second time points are different from each other, if they belong to the same first period, the user PC 30 performs the first conversion. The user PC 30 performs a second conversion on the TUID when the TUID is converted at a third point in time that belongs to a second period different from the first period. The authentication server 20 performs the first inverse conversion during the first period to obtain the TUID. The authentication server 20 performs the second inverse conversion in the second period to obtain the TUID. As a result, different conversions can be performed in the first and second periods, so even if a third party somehow acquires the mechanism of the first conversion, they will not be able to use the first conversion in the second period. This improves communication security.
Furthermore, the user PC 30 performs the first conversion by converting the TUID based on the first salt. The authentication server 20 performs the first inverse conversion by inversely converting the converted TUID based on the first salt. This gives the transformation function f and the inverse transformation function f<sup>-1</sup>Security in communication is increased by changing the salt used depending on the period without changing the data.
Further, each of the authentication server 20 and the user PC 30 obtains a first salt corresponding to the combination of the day and time zone indicated by the first period. As a result, the period during which the first salt is valid can be set for each time period, so the period during which the first salt is valid can be made relatively short. Even if a third party acquires the first salt, the period during which the first salt can be used is short, so security in communication is effectively increased.
Further, each of the authentication server 20 and the user PC 30 obtains the first salt associated with the first period in the salt database DB1. This eliminates the need to generate the first salt on the spot by storing the first salt in the salt database DB1 in advance, thereby simplifying the processing required during communication. As a result, the processing load on the salt server 10 is reduced, and the time required to complete the authentication process is shortened.
The salt server 10 also updates the salt database DB1. This prevents the same salt from being used for a long period of time, increasing security in communication.
Further, each of the authentication server 20 and the user PC 30 transmits a salt request to the salt server 10. Salt server 10 transmits the first salt to each of authentication server 20 and 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, so that the processing load in communication can be distributed. That is, the processing necessary for communication can be distributed between the salt server 10 and the authentication server 20. Therefore, the processing load on the authentication server 20 can be reduced.
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 they steal the salt request. For example, even if a salt corresponding to the day and time zone has been acquired, the acquisition rule cannot be determined only by the salt request, which further increases security in communication.
Further, the authentication server 20 executes authentication processing based on the TUID obtained by the first inverse conversion, and generates a new TUID if the authentication processing is successful. This increases security during authentication. For example, since the TUID changes each time the user logs in, even if a third party attempts the cross-site scripting attack described above, authentication cannot be successful, and spoofing can be prevented.
[2.Second embodiment]
In the first embodiment, a case has been described in which salts depending on the day and time zone are used. The salt acquisition method is not limited to the example of the first embodiment. In the second embodiment, a case will be described in which a salt is used depending on a combination of the date on which the salt is acquired and a part of the TUID. In the subsequent second and third embodiments, descriptions of the same points as in the first embodiment will be 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 the same as in the first embodiment, but the salt acquisition method is different from the first embodiment. For example, the salt database DB1 stores salts 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 "00" of the TUID "312400" to the salt server 10. Even if a malicious third party steals the last two digits of the TUID, they will not be able to steal the TUID itself, nor will they be able to figure out the rules for obtaining the salt from just the number "00".
When the salt server 10 receives the salt request, it refers to the salt database DB1 and obtains the salt according to the combination of the current day and the last two digits of the TUID included in the salt request. In the example of FIG. 8, the salt "6435" corresponding to "2nd", which is the day when the salt server 10 received the salt request from the user PC 30, and "00", which is the last two digits of the TUID, is sent to the user PC 30. Send to.
When the user PC 30 receives the salt "6435" from the salt server 10, it converts the TUID "312400" based on the salt "6435". In the example in Figure 8, the conversion function f is used to add the last two digits of TUID "00" after "9559", which is the first four digits of TUID "3124" and the salt "6435", so after the conversion The TUID of will be "955900". The user PC 30 transmits to the authentication server 20 an authentication request including the user's face photo generated by the photographing unit 36 and the converted TUID "955900".
Upon receiving the authentication request, the authentication server 20 transmits 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 a salt request, it refers to the salt database DB1 and stores the data according to the combination of the current day "2nd" and the last two digits of the TUID included in the salt request "00". The received salt "6435" is sent to the authentication server 20.
Upon receiving the salt "6435" from the salt server 10, the authentication server 20 reversely transforms the converted TUID "955900" received from the user PC based on the salt "6435". In the example in Figure 8, the conversion function adds the last two digits of the converted TUID "00" after the value obtained by subtracting the salt "6435" from the first four digits "9559" of the converted TUID "955900". f<sup>-1</sup>is used. The authentication server 20 obtains the first four digits "3124" of the TUID through 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 and 302 acquire a salt corresponding 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 parts that explain the last two digits of the TUID can be read as part of the TUID. The TUID portion 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 it may be the second to fourth digits of the TUID. A portion of the TUID does not have to be consecutive digits, such as the first digit and the last digit of the TUID. The length of a portion of the TUID may also be arbitrary.
In the second embodiment, when the salt acquisition unit 203, 302 acquires the salt according to the date when the salt is acquired (an example of the first period) and the last two digits of the TUID (an example of a part of the original data), However, the salt acquisition units 203 and 302 may acquire the salt according to the time period in which the salt is acquired and the last two digits of the TUID. In this case, it is assumed that a salt is defined for each combination in the salt database DB1. By combining the first embodiment and the second embodiment, the salt acquisition units 203 and 302 may acquire salts according to three combinations of day, time zone, and last two digits of TUID. In this case, it is assumed that salts are defined for each of these three combinations in the salt database DB1.
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 conversion 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 6 digits, the remaining part is the first 4 digits. The conversion method using salt is the same as described in the first embodiment.
The transmitter 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 theory. In the second embodiment, a case will be described where these last two digits are included as the last two digits of the converted TUID, but these last two digits may be sent as information separate from the converted TUID. . Even if these last two digits are included in the converted TUID and transmitted, they may be added at a different position (for example, the first two digits) from the original position (lower two digits). The last two digits are an example of a portion that has not been converted. Therefore, the part that explains the last two digits can be read as the unconverted part. As mentioned above, this part 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, so by receiving the converted TUID, the receiving unit 201 Receive 2 digits. If the last two digits of the unconverted TUID are sent as different information from the converted TUID, the receiving unit 201 only needs to receive the last two digits of the unconverted TUID sent as the different information. . The salt acquisition unit 203 acquires a salt according to the date on which the salt is acquired (an example of the first period) and the last two digits of the unconverted TUID. The salt acquisition method by the salt acquisition unit 203 is the same as the salt acquisition method by the salt acquisition unit 302.
The first inverse transformation of the second embodiment is an inverse transformation according to the first period and the unconverted portion. The inverse conversion unit 204 inversely converts the remaining part (first four digits) of the converted TUID, which is an example of the first converted data, based on the inverse conversion information, obtains the remaining part, and combines the remaining part with the unconverted part. Get the TUID based on part of the transformation. In the example of FIG. 8, the inverse conversion unit 204 obtains the first four digits of the TUID "3124" by inverse conversion, so the first four digits "3124" and the last two digits "00" received from the user PC 30 are , to get the TUID "312400". In the example in Figure 8, we will explain the case where the first four digits "3124" and the last two digits "00" are added, but the original data TUID is obtained based on a predetermined combination rule. do it.
According to the communication system S of the second embodiment, the user PC 30 obtains a first salt corresponding 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 corresponding to the first period and the last two digits of the unconverted TUID. This increases the security of multi-factor authentication by transmitting the converted TUID over the network and making it difficult for third parties to obtain the TUID. Even if a malicious third party were to steal the salt request, it would be difficult to understand the conversion mechanism using just the last two digits of the TUID, which further increases the security of communications.
Further, the user PC 30 generates the first four digits of the converted TUID by converting the first four digits of the TUID, which are the remaining portion other than the last two digits, based on the first salt. The authentication server 20 obtains the first four digits of the TUID by inversely converting the first four digits of the converted TUID based on the first salt, and based on the first four digits and the unconverted last two digits. and get the TUID. Thereby, even if the TUID is divided into multiple parts, the authentication server 20 can obtain a single TUID and complete the authentication process reliably.
[3. Third embodiment]
In the first embodiment and the second embodiment, a case has been described in which security in communication is increased by devising a salt acquisition method. The method of increasing security in communication is not limited to the examples of the first embodiment and the second embodiment. In the third embodiment, the user PC 30 uses different conversion functions f depending on the time period in which the TUID is converted, thereby increasing security in communication. The user PC 30 stores a plurality of 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 the same as in the first embodiment and the second embodiment. In the example of FIG. 9, a salt acquisition method similar to that of the first embodiment is exemplified. The flow until the user PC 30 acquires the salt is the same as in the first embodiment. The user PC 30 obtains the salt "8414" corresponding to the current day "2nd" and the time zone "01 o'clock" from the salt server 10.
In the third embodiment, the user PC 30 uses different conversion functions f based on the time period in which the TUID is converted. For example, the user PC 30 stores conversion functions f0 to f23 corresponding to time zones "00:00" to "23:00", respectively. Hereinafter, when the conversion functions f0 to f23 are not distinguished, they will simply be referred to as conversion function f. It is assumed that the calculation methods indicated by the individual conversion functions f are different from each other. Therefore, even if the salt is the same, if the conversion function f is different, the TUID value after conversion will be different.
In the example of FIG. 9, the user PC 30 selects the conversion function f1 from among the conversion functions f0 to f23 because the time slot for converting the TUID is "01 o'clock." It is assumed that the conversion function f1 is the same as the 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 sends the converted TUID to the authentication server 20. Upon receiving the converted TUID, the authentication server 20 acquires the salt from the salt server 10 in the same manner as in the first embodiment.
In the third embodiment, the authentication server 20 uses the inverse conversion function f based on the time period for converting the TUID.<sup>-1</sup>Use them properly. For example, the authentication server 20 uses the inverse transformation function f corresponding to the time zones "00:00" to "23:00".<sup>-1</sup>0~f<sup>-1</sup>Remember 23. Hereafter, the inverse transformation function f<sup>-1</sup>0~f<sup>-1</sup>23, simply use the inverse transformation function f<sup>-1</sup>It is written as individual inverse transformation function f<sup>-1</sup>The calculation methods shown are different from each other. Therefore, even if the salt is the same, the inverse transformation function f<sup>-1</sup>If the values are different, the value of TUID after inverse conversion will also be different.
individual inverse transformation function f<sup>-1</sup>The calculation method shown corresponds to the conversion function f that uses the same time zone. In order to obtain an accurate TUID, use the inverse conversion function f that corresponds to the conversion function f used by user PC30.<sup>-1</sup>You need to perform the inverse transformation. In the example in Figure 9, the time period for inversely converting the TUID is "01 o'clock", so the inverse conversion function f<sup>-1</sup>0~f<sup>-1</sup>Out of 23, the inverse transformation function<sup>-1</sup>Select f1. 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 an accurate 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 implemented in the communication system S of the third embodiment. As shown in FIG. 10, in the third embodiment, an inverse transformation function selection section 208 and a transformation function selection section 306 are implemented. The inverse transformation function selection section 208 is realized mainly by the control section 21. The conversion function selection section 306 is realized mainly by the control section 31.
Conversion function selection section 306 selects a first conversion method according to the first period from among the plurality of conversion functions f. The conversion function f is an example of the first conversion method. Therefore, the portion where the conversion function f is explained can be read as a conversion method. The conversion method is a method of converting TUID. The conversion method is not limited to the conversion function f, as long as it defines how to convert the TUID. For example, the conversion method may be a calculation formula that is not called a function, or an encryption algorithm. For example, the conversion method may also be a file compression algorithm.
The conversion function selection unit 306 may select any one of the plurality of conversion functions f based on a predetermined selection method. In the third embodiment, a case will be described in which a time zone is used as an example of a selection method. Conversion function selection section 306 selects conversion function f according to the time period. It is assumed that the relationship between the time zone and the conversion function f is defined in the data storage unit 300 in advance. Conversion function selection section 306 selects conversion function f corresponding to the current time zone. In the third embodiment, the numerical values "00" to "23" indicated by the time zone and the numerical values included in the conversion functions "f0" to "f23" correspond to each other.
In the third embodiment, the time slot is an example of the first period. Therefore, the portions that describe the time period can be read as the first period. In the third embodiment, a case will be described in which the first period is indicated by a time zone, but the first period may be indicated by a combination of a day and a time zone as in the first and second embodiments. However, it may also be expressed in days only. Even if the first period has a different meaning, the conversion function selection unit 306 selects the conversion function f according to the time zone indicated by the first period. It is assumed that the relationship between each period and the conversion function f is defined in the data storage unit 300 in advance.
The conversion unit 303 performs the 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>From among, the inverse transformation function f according to the first period<sup>-1</sup>Select. 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 part where this is explained can be read as the first inverse transformation method. The first inverse conversion method is a method of inversely converting the converted TUID. The inverse conversion method may be any method that defines how to inversely convert the TUID after conversion, and the inverse conversion function f<sup>-1</sup>Not limited to. For example, the inverse transformation method may be a calculation formula that is not called a function, or a decoding algorithm. For example, the reverse conversion method may be a file decompression algorithm.
The inverse transformation function selection unit 208 selects a plurality of inverse transformation functions f based on a predetermined selection method.<sup>-1</sup>You can choose one of them. In the third embodiment, a case will be described in which a time zone is used as an example of a selection method. The inverse transformation function selection unit 208 selects an inverse transformation function f according to the time period indicated by the first period.<sup>-1</sup>Select. time zone and inverse transformation function f<sup>-1</sup>It is assumed that the relationship is defined in the data storage unit 200 in advance. The inverse transformation function selection unit 208 selects an inverse transformation function f corresponding to the current time zone.<sup>-1</sup>Select. 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>As, the inverse transformation function f according to the first transformation period<sup>-1</sup>Select.
The inverse transformation unit 204 uses the inverse transformation function f selected by the inverse transformation function selection unit 208.<sup>-1</sup>The first inverse transformation is performed by inversely transforming the converted TUID based on . Inverse transformation function f selected by inverse transformation function selection unit 208<sup>-1</sup>This embodiment differs from the first and second embodiments in that the following is used; however, they are similar in other respects.
According to the communication system S of the third embodiment, the user PC 30 selects the conversion function f according to the first period from among the plurality of conversion functions f, and converts the TUID. The authentication server 20 uses a plurality of inverse transformation functions f<sup>-1</sup>From among, the inverse transformation function f according to the first period<sup>-1</sup>Select and reverse convert 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, thereby increasing communication security. Furthermore, since the conversion function f changes dynamically, it becomes difficult for a third party to understand the conversion mechanism, further increasing security in communication.
Further, the user PC 30 selects the conversion function f according to the time zone indicated by the first period. The authentication server 20 uses an inverse transformation function f according to the time period indicated by the first period.<sup>-1</sup>Select. As a result, the conversion function f changes according to a shorter period of time, which further reduces the frequency of using the same conversion function f and makes it difficult for third parties to understand the conversion mechanism.
[4. Modification example]
Note that the present disclosure is not limited to the first to third embodiments described above. Changes can be made as appropriate without departing from the spirit of the present disclosure.
[4-1. Modification example 1]
For example, in the example of FIG. 2 of the first embodiment, the time point when the salt request from the user PC 30 is accepted is "December 2, 2021 01:59:59", and the salt request from the authentication server 20 is accepted. Assume that the time when the request was made was "December 2, 2021 02:00:00". In this case, the salt that the user PC 30 obtains is "8414" and the salt that the authentication server 20 obtains is "9436." In this case, the salt used for converting the TUID and the salt used for inversely converting the converted TUID are different, so the authentication server 20 cannot obtain an accurate TUID. Therefore, in modification example 1, a case will be described in which the user PC 30 sends to the authentication server 20 information that can identify which time zone the salt used in TUID conversion is from.
FIG. 11 is a diagram illustrating an example of the flow of multi-factor authentication in Modification 1. In the first modification, 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 sends to the user PC 30 a first salt according to the day and time period to which the current time belongs, and a second salt according to the next time period. do.
In the example of FIG. 11, the time point when the salt request from the user PC 30 is accepted is "December 2, 2021 01:59:59". Salt server 10 has the first salt "8414" corresponding to "2nd" and "01 o'clock" and the second salt corresponding to "2nd" and "02 o'clock" which are the next time zone. The pair "9436" is sent to the user PC 30. The user PC 30 receives the salt pair "8414" and "9436" from the salt server 10.
The user PC 30 selects one of the salt pairs "8414" and "9436." The user PC 30 may select the salt based on a predetermined selection method. In the first modification, a case will be exemplified in which it is decided to select the first salt, 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 it sends a salt request, the time it receives a salt pair, or the time it selects a salt.
In the example of FIG. 11, the user PC 30 converts the TUID "312456" based on the first salt "8414". The TUID after conversion will be "320870". The user PC 30 transmits to the authentication server 20 the converted TUID "320870" and a timestamp "59:59" that can identify the time zone corresponding to the first salt "8414". This timestamp could be the current time "December 2, 2021 01:59:59", but in order to reduce the amount of information obtained by third parties, only "59:59" is sent. shall be carried out. As the timestamp, any of the time when the salt request is sent, the time when the salt is received, the time when the TUID is converted, or the time when the converted TUID is sent may be used.
Upon receiving the converted TUID "320870" and the timestamp "59:59", the authentication server 20 transmits a salt request to the salt server 10. When the salt server 10 receives a salt request from the authentication server 20, it sends to the authentication server 20 a pair of a salt corresponding to the current day and time period and a salt corresponding to the next or previous time period. .
In the example of FIG. 11, the time point 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 has the first salt "8414" corresponding to "2nd" and "01 o'clock" and the second salt server 10 corresponding to "2nd" and "02 o'clock" which are the next time zone. The pair of the first salt "9436" is sent to the authentication server 20. The authentication server 20 receives the salt pair "8414" and "9436" from the salt server 10.
On the other hand, assume that 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 server 10 uses the first salt "8414" corresponding to the previous time zone "2nd" and "01 o'clock" and the time zone to which the current time zone belongs "2nd" and "02 and the second salt ``9436'' corresponding to ``time'' to the authentication server 20. The authentication server 20 receives the salt pair "8414" and "9436" from the salt server 10. In this way, the salt server 10 sends the salt of the previous time period or the salt of the next time period depending on whether it is immediately before or after the time period break. or may be controlled.
The authentication server 20 can identify, from the timestamp "59:59" received from the user PC 30, that a salt in a relatively earlier time zone was used in the conversion. That is, it can be determined that the first salt of the salt pair received from the authentication server 20 was used. The authentication server 20 performs inverse 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, assume that the time stamp 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 identify, based on this timestamp, that a salt in a relatively later time zone was used in the conversion. That is, the authentication server 20 performs the inverse transformation based on the second salt "9436".
In the example of FIG. 11, assume that the time when the salt server 10 accepted the salt request from the user PC 30 was "December 1, 2021, 23:59:59." Salt server 10 has the first salt "8201" corresponding to "1st" and "23:00" and the second salt "6435" corresponding to "2nd" and "00:00" of the next day. , may be sent to the user PC 30.
The transmitter 304 further transmits first period information regarding the first period to the authentication server 20. In the example of FIG. 11, "01 o'clock" on "2nd" corresponds to the first period. The first period information is information that allows identification of 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 time stamp "59:59" can be read as 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 the time stamp "59:59" from the user PC 30 as the first period information. 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 explained in the first to third embodiments.
When the salt server 10 receives a request from the authentication server 20 in the second period after the first period, the salt server 10 sends the authentication server 20 a salt according to the first period and a salt in the second period. Send multiple salts, including the corresponding salt. The combination of day and time zone is an example of the second period. Therefore, the portions that explain combinations of days and time zones can be read as the second period.
In the example of FIG. 11, the first period is "01 o'clock" on "2nd". The end point of this first period is the point immediately before "02:00:00" on "2nd" (for example, "01:59:59" on "2nd"). In the example of FIG. 11, the first point in time "December 2, 2021 01:59:59" is the same as or close to the end point, so the salt server 10 The salt "8414" for "01 o'clock" and the salt "9436" for "02 o'clock" of "2nd" which is the second period after the first period are transmitted.
For example, immediately after the start of the first period, the salt server 10 transmits a plurality of salts including a salt corresponding to the first period and a salt corresponding to the third period before the first period. Immediately after the start means within a predetermined time (for example, within several 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 "2nd". The starting point of this first period is "02:00:00" on "2nd day". Since the first time point "December 2, 2021 02:00:00" is the same as or immediately after this start time, the salt server 10 will Send the salt "8414" for "01 o'clock" and the salt "9436" for "02 o'clock" of the first period "2nd".
The salt acquisition unit 203 acquires a salt corresponding to the first period based on the first period information. The salt acquisition unit 203 acquires a salt corresponding to the first period from among the 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 salt pairs 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 the temporally previous 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, assume that the timestamp is "00:00" instead of "59:59". In this case, the salt acquisition unit 203 can specify from the timestamp "00:00" that a later salt in time 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 obtains the first salt based on the timestamp received from the user PC 30. This allows the inverse transformation to be performed accurately even if the first salt is obtained near the end of a certain time period. Therefore, it is possible to eliminate the trouble of retrying multi-factor authentication if it fails, thereby increasing convenience for the user. Since the salt server 10, the authentication server 20, and the user PC 30 do not execute unnecessary processing, their processing loads can be reduced.
Further, when the salt request from the authentication server 20 is received in the second period after the first period, the salt server 10 sends the authentication server 20 a salt corresponding to the first period and a second period. 2Send multiple salts, including salts according to the period. The authentication server 20 selects a first salt to be used in inverse transformation from among a plurality of salts based on a timestamp, which is an example of first period information. This makes it possible to accurately perform inverse transformation, thereby saving the effort of redoing multi-factor authentication if it fails.
[4-2. Modification example 2]
For example, as in the third embodiment (FIG. 9), the transformation function f and the inverse transformation function f<sup>-1</sup>Even if , the same problem as Modification 1 may occur. For example, 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 reverse conversion is "December 2, 2021 02:00:00". Suppose that In this case, the conversion function f of TUID and the inverse conversion function f of TUID after conversion<sup>-1</sup>and do not correspond, the authentication server 20 may not be able to obtain an accurate TUID.
Therefore, in modification 2, similarly to modification 1, it is assumed that user PC 30 transmits a timestamp "59:59" to authentication server 20. Based on this time stamp, the authentication server 20 uses the inverse transformation function<sup>-1</sup>You can specify what you need to do by using The transmitter 304 further transmits the first period information to the authentication server 20.
If the timing at which the salt request is sent from the user PC 30 to the salt server 10 is as shown in FIG. 11, then "01 o'clock" on "2nd" corresponds to the first period. The first period information of modification 2 is the inverse transformation function f of which period.<sup>-1</sup>This is the information that allows you to identify which one should be used. In the above example, the timestamp "59:59" corresponds to the first period information. Therefore, the part explaining the time stamp "59:59" can be read as first period information. The receiving unit 201 further receives first period information from the user PC 30.
The inverse transformation function selection unit 208 selects an inverse transformation function f according to the first transformation period based on the first period information.<sup>-1</sup>Select. inverse transformation function f<sup>-1</sup>The inverse transformation function f is based on the first period information rather than the time point of selecting<sup>-1</sup>This embodiment differs from the third embodiment in that the following is selected; however, other points are similar to the third embodiment. The inverse transformation function selection unit 208 selects a plurality of inverse transformation functions f based on the first period information.<sup>-1</sup>From among, the inverse transformation function f according to the first transformation period<sup>-1</sup>All you have to do is select.
According to the communication system S of the second modification, the user PC 30 transmits first period information regarding the first conversion period to the authentication server 20. The authentication server 20 generates an inverse transformation function f according to the first transformation period based on the first period information received from the user PC 30.<sup>-1</sup>Select. This increases security in multi-factor authentication. Multi-factor authentication can be performed accurately even if the TUID conversion is performed near the end of a certain time period. Therefore, it is possible to eliminate the trouble of retrying multi-factor authentication if it fails, thereby increasing convenience for the user. Since the salt server 10, the authentication server 20, and the user PC 30 do not execute unnecessary processing, their processing loads can be reduced.
[4-3. Modification example 3]
For example, before the user logs in, a malicious third party uses a cross-site scripting attack or the like to access the TUID in the user PC 30, the conversion function f, and the access method to the salt server 10 (for example, to a specific IP address). Suppose that the flow of sending the getSalt() command to obtain the salt) and the user's facial photo are stolen. In this case, even if the TUID is updated every time the user logs in, a third party will still be able to impersonate the user because they will have access to the salt server 10 and the information necessary for authentication. There is a fear.
Therefore, when a user registers information such as a face photo in the authentication server 20, or logs in using a user ID and password in a secure manner, the user PC 30 uses information based on multiple pieces of information about itself. A hash value may be generated and sent to the authentication server 20. This hash value is stored in the user database DB2 in association with the user ID. When a user performs authentication using TUID and logs in, the transmitting unit 304 of the user PC 30 sends the converted TUID and a hash value based on multiple pieces of information regarding the user PC 30 to the authentication server 20. Send. As described in the first embodiment and the like, the transmitter 304 also transmits the user's face photo.
The processing execution unit 205 of the authentication server 20 executes authentication processing based on the TUID obtained by the first inverse transformation and the hash value. The communication system S described in the first embodiment uses not only TUID authentication but also face authentication, so the processing execution unit 205 performs authentication processing based on the TUID, facial features, and hash values. Execute. Therefore, the authentication process in Modification 3 is three-factor authentication. Authentication using TUID and facial feature amounts is as described in the first embodiment. The processing execution unit 205 determines whether the hash value received from the user PC 30 matches the hash value stored in the user database DB2 in association with the user ID of the user. If these match, authentication using the hash value is successful.
Note that any information can be combined as the plurality of 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 user PC 30, the type of operating system, and the type of browser. Alternatively, the hash value may be generated based on other information such as the serial number of the user PC 30, the SIM card number, or the MAC address of the communication card. Various hash functions can be used as the hash function itself for generating the hash value. It is assumed that 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 third modification, security is enhanced by authentication using a hash value. For example, even if a malicious third party illegally obtains the TUID, etc. in the user PC 30, there is a high possibility that the hash value cannot be identified, thereby increasing security.
[4-4. Modification example 4]
For example, the communication system S can be applied to situations other than those where authentication processing is performed. Other situations include sending an email, uploading or downloading a file, posting on SNS, displaying a page in a browser, or when a user uploads or downloads personal information. The communication system S can also be applied to other screens.
For example, if the communication system S is applied to a situation where an e-mail is sent, the first device is a computer on the sending side of the e-mail, and the second device is a computer on the receiving side of the e-mail. The original data is email data. The original data includes the body of the email. When an attachment is attached to an e-mail, the original data includes the attachment. The first device generates first converted data by performing a first conversion on the original data, which is an email, based on a first salt corresponding to a first period. The first converted data is an email after conversion. The first device transmits the first converted data, which is the converted email, to the second device. Upon receiving the first converted data, the second device performs the first inverse conversion based on the first salt and obtains the email that is the original data. The method for obtaining the first salt is as explained in the first to third embodiments and the first to third modified examples.
For example, if the communication system S is applied to the scene of uploading a file, the first device is a user's computer that 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 generates first converted data by performing a first conversion on original data, which is a file to be uploaded, based on a first salt corresponding to a first period. The first converted data is a converted file. The first device transmits first converted data, which is a converted file, to the second device. Upon receiving the first converted data, the second device performs the first inverse conversion based on the first salt to obtain a file that is the original data. The salt acquisition method is as explained in the first to third embodiments and the first to third modified examples.
The same applies when the communication system S is applied to other situations, and the first device only needs to perform the first conversion on the original data according to the first period. The second device may perform the first inverse transformation on the first converted data according to the first period. According to the communication system S of Modification 4, the security of communication in various situations is enhanced.
[4-5. Other variations]
For example, the first to third embodiments may be combined. The above modifications may be combined.
For example, the process of Modification 1 or Modification 2 may be executed only near the end of a certain time period. For example, the functions described as being implemented by the salt server 10 may be implemented 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, when the communication system S includes multiple server computers, functions may be shared among the multiple server computers. Further, for example, the data described as being stored in the data storage units 100 and 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 | Category | Cited during | Relevant claims |
|---|---|---|---|---|---|
| JP2000244474A | Cites | Japan | Y | Search report | 7-9,17-19 |
| JP2001524771A | Cites | Japan | Y | Search report | 8-9,17-19 |
| JP2006340296A | Cites | Japan | XY | Search report | 1-4,10-11,20-22,6-9,12-19 |
| JP2007156785A | Cites | Japan | Y | Search report | 17-19 |
| JP2017531967A | Cites | Japan | A | Search report | 1-22 |
| JP2689383B2 | Cites | Japan | – | Search report | – |
| JPH10242956A | Cites | Japan | A | Search report | 1-22 |
| JP2006340296A | Cites | Japan | – | – | – |
| JP10242956A | Cites | Japan | – | – | – |
| JP2017531967A | Cites | Japan | – | – | – |
| JP2000244474A | Cites | Japan | – | – | – |
| JP2001524771A | Cites | Japan | – | – | – |
| JP2007156785A | Cites | Japan | – | – | – |
11 members in 5 offices
Priority claims1
| Document | Office | Kind | Date |
|---|---|---|---|
| 2022008319 | Japan | W |
Members11
| Document | Office | Kind | |
|---|---|---|---|
| JPWO2023162232A1 | Japan | A1 | |
| WO2023162232A1 | World Intellectual Property Organization (WIPO) | A1 | |
| TW202337168A | Taiwan Province of China | A | |
| JP7358659B1This record | 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 | |
| JP7603764B2 | Japan | B2 | |
| US12388800B2 | United States of America | B2 |
11 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| 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 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 | |
| Explanation of circumstances concerning accelerated examinationJAPANESE INTERMEDIATE CODE: A871A871 | A871 |
Numbers
- Publication
- 7358659
- Application
- 577694
Titles2
- Japanese
- 通信システム、通信方法、及びプログラム
- English
- Communication system, communication method, and program
Classification
- CPC, 5
- H04L9/3297
- H04L63/0428
- H04L9/16
- H04L9/3271
- H04L9/30
- IPC, 2
- H04L9 16
- H04L9 32