TWM520168U - System generating multiple factor pledge - Google Patents

Description

System for generating multi-factor tokens

A system for generating multi-factor tokens, and more particularly to a system for generating multi-factor tokens based on digital credentials and verification data.

With the popularity of the Internet and the rapid development of related applications, part of the traditional business behavior is gradually turned to online, and the convenience of online transactions allows people to go online without going out. The number of online transactions has grown exponentially in recent years by finding the goods they need and trading them. However, online transactions are conducted remotely through the Internet. Payments must be based on specific currency types, such as credit cards, financial cards, etc., and such transactions must be transmitted over the network during the transaction. Including user data and payment information, online transactions require a safer authentication method to protect user data than traditional business practices. Other related applications such as online banking, securities futures orders, and natural person data queries also require secure authentication methods to protect user data.

At present, the common security authentication methods on the market can be divided into two categories. The first type is to use a fixed password. The user inputs the user name and the fixed password on the computer. The problem with this method is that it is easy to be transmitted when the data is transmitted through the Internet. Internet hackers record or monitor, causing data leakage, so the security is insufficient; the second type is the use of One Time Password (OTP), randomly generating different passwords according to different transactions or different events in the same transaction. Since a password is used only once, it can prevent the password from being stolen. This method can be mainly divided into three types according to the software and hardware to which it is matched. The first one is to use a hardware that can generate a dynamic password. For example, a dynamic password generator is used to randomly generate a dynamic password for the transaction. However, this type of procurement and construction cost is high and the user needs to keep the hardware and carry it with him, which is inconvenient to use; the second is Using a newsletter with a mobile phone, this type is generated by the server after the dynamic password is generated, and the dynamic password is sent to the user's mobile phone through the short message, because the mobile phone Carrying, so it solves the problem that the first type is not easy to carry. However, the confidentiality of the newsletter is not high, and when the Subscriber Identity Module (SIM) card is fraudulently used, others can also receive the dynamics. The password is used to impersonate the user to conduct the transaction; the third is to use the PUSH message to match the smart phone. This type is generated by the server after the dynamic password is generated, and the dynamic password is sent to the user's smart phone through the PUSH message. Solved the problem that the first type is not easy to carry, and the PUSH message will only be transmitted to the authenticated smart phone, which also solves the problem that the user identification module card is fraudulently used. However, once the mobile phone is lost, others still You can operate the user's mobile phone for online transactions.

In summary, it can be seen that the security authentication of online transactions has not been undeniable for a long time in the prior art, and therefore it is necessary to propose an improved technical means to solve this problem.

In view of the fact that there is no undeniable security certification for online transactions in the prior art, the present disclosure discloses a system for generating multi-factor tokens, in which:

The system for generating multi-factor tokens disclosed in the present invention includes at least: a token application host for receiving real-name authentication information corresponding to the client, and applying for a digital certificate according to the real-name authentication information; the token management host is configured to use the digital certificate and The real-name authentication information generates a multi-factor token corresponding to the client.

The system disclosed in the present application is as above, and the difference from the prior art is that the present application applies a digital certificate by real-name authentication information by real-name authentication, and generates a multi-factor token based on the applied digital certificate and real-name authentication information, so that the client can The online transaction is completed according to the multi-factor transaction, so as to solve the problems existing in the prior art, and the technical effect of reducing the cost of providing the dynamic password can be achieved.

The features and implementations of the present invention will be described in detail below in conjunction with the drawings and the embodiments, which are sufficient to enable any skilled person to fully understand the technical means to which the present invention solves the technical problems and implement them accordingly. The achievable effect of this creation.

This creation can provide the client to apply for multi-factor tokens online after completing the real-name authentication, and provide multi-factor tokens applied by the client installation, so that the client can complete the online transaction using the installed multi-factor tokens.

Among them, the client mentioned in this creation can be a device with communication function and data processing capability such as a smart phone or a computer. The real name authentication mentioned in the creation is a method for authenticating the identity of the user of the client, for example, : identification by cabinet, use mobile phone number authentication, use email account or social media account authentication, use financial card or credit card and other financial payment instrument authentication, use certificate or public key authentication, use online banking password authentication, use install application Application authentication code generated during the program, etc., but this creation is not limited to this.

The following is a description of the system architecture of the creation of multi-factor tokens in the "Picture 1". As shown in "FIG. 1", the system of the present creation includes a token application host 120 and a token management host 130.

The token application host 120 is responsible for receiving the real-name authentication information corresponding to the client 150, and applying the digital certificate according to the received real-name authentication information, and providing the applied digital certificate to the token management host 130. The real-name authentication information provided by the present application includes information about the applicant for the token application host 120 to apply for a digital certificate, such as the applicant's name, contact information, and the like, and also includes information sufficient to identify the client 150, for example, the customer The network address of the terminal 150, the serial number of the client 150, the MAC address of the client 150, and the like.

In some embodiments, the token application host 120 can obtain installation target information corresponding to the client 150. The installation target information obtained by the token application host 120 may include the installation target of the multi-factor token, such as the application name or the storage path, but the installation target information proposed by the creation is not limited to the above.

The token application host 120 may further include a security control component 123 and a certificate authority (RA) 125.

The security control component 123 is responsible for providing the real name authentication server 401 to connect with the token application host 120 and verifying the connected real name authentication server 401.

The security control component 123 is also responsible for providing the real-name authentication server 401 to transmit the real-name authentication information corresponding to the client 150 to the token application host 120 after the connected real-name authentication server 401 passes the verification.

The voucher registration center 125 is responsible for reading the necessary information in the real-name authentication information transmitted by the real-name authentication server 401, and applying the read data as the applicant data to the certificate authority (CA) 405 for applying for the digital certificate. And receiving the digital certificate signed and returned by the certificate issuing center 405.

The token management host 130 is responsible for receiving the digital certificate transmitted by the token application host 120 and the real-name authentication information, and generating a multi-factor token corresponding to the client 150 according to the received digital certificate and the real-name authentication information.

The multi-factor token generated by the token management host 130 includes a credential corresponding to the client 150 and verification data corresponding to the client 150. In general, the token management host 130 can generate verification data corresponding to the client 150 according to the received real-name authentication information. The verification data provided by the creation is information that is not repeated and is sufficient to identify the client 150. For example, when the client is a mobile phone, the verification data may be a mobile phone serial number; if the client is a desktop computer or a notebook computer, the verification data may be a network card number, etc., but the verification data provided by the creation is not the above. Limited.

In some embodiments, the credentials contained in the multi-factor beacon generated by the token management host 130 may be encrypted, that is, the client 150 needs to provide the user to input a password before decrypting according to the password input by the user, and Decrypted credentials are used in the online transaction process.

The token management host 130 can also transmit the generated multi-factor tokens to the corresponding client 150, so that the client 150 installs a corresponding multi-factor token, so that the client 150 can use the multi-factor token to complete the online transaction.

Next, the operation system and method of the present creation are explained by an embodiment, and please refer to the flowchart of the method for generating multi-factor tokens proposed in the "Fig. 2". In this embodiment, it is assumed that the client 150 is a smart phone, but the creation is not limited thereto.

First, the real name authentication server 401 can provide the client 150 with real name authentication (step 202). The user can operate the client 150 to connect to the real-name authentication server 401, and can use the email account and the mobile phone number for real-name authentication, or use the financial payment tool and the mobile phone number for real-name authentication, or can use the online banking password and The mobile phone number is authenticated by real name. In this embodiment, it is assumed that the user uses the voucher and the mobile phone number for real name authentication.

After the real name authentication server 401 completes the real name authentication of the user, the real name authentication server 401 can transmit the real name authentication information corresponding to the client 150 to the token application host 120 for online registration (step 210). In this embodiment, the real name authentication server 401 can be connected to the token application host 120 through the security control component 123 of the token application host 120, and will be associated with the client 150 after the security component 123 of the token application host 120 is allowed to connect. The corresponding real name authentication information is transmitted to the token application host 120.

After the token application host 120 receives the real-name authentication information corresponding to the client 150, the credential registration center 125 of the token application host 120 may apply for the digital credential corresponding to the client 150 according to the received real-name authentication information (step 220). ). In this embodiment, it is assumed that the credential registration center 125 of the token application host 120 can read the necessary information of the application digital certificate from the received real-name authentication information, and transmit the necessary information read out to the voucher through the network. The center 405 is issued and receives the digital certificate signed and returned by the voucher publishing center 405.

After the token application host 120 applies for the digital certificate corresponding to the client 150, the token application host 120 can transmit the applied digital certificate and the received real-name authentication information to the token management host 130 (step 250). The client 150 applies for a multi-factor token corresponding to the client 150.

After the token management host 130 receives the digital certificate applied by the token application host 120 and the received real-name authentication information, the token management host 130 may generate a corresponding identifier corresponding to the client 150 according to the received digital certificate and the real-name authentication information. Multi-factor tokens (step 260). In this embodiment, it is assumed that the token management host 130 can read the mobile phone serial number of the client 150 from the real-name authentication information, and merge the read mobile phone serial number with the received digital voucher to correspond to the client 150. Multi-factor beacon.

After the token management host 130 generates a multi-factor token corresponding to the client 150, the token management host 130 can transmit the generated multi-factor token to the corresponding client 150 (step 270). In this embodiment, it is assumed that when the client 150 is connected to the real-name authentication server 401, the installation target information is transmitted to the real-name authentication server 401, and the real-name authentication server 401 transmits the installation target information together with the real-name authentication information to the token. After registering the host 120, the token registration host 120 also transmits the installation target information together when transmitting the digital certificate and the real-name authentication information to the token management host 130. Thus, the token management host 130 can be based on the received installation target information. The generated multi-factor beacon is transmitted to the client 150.

After the client 150 receives the multi-factor token transmitted by the token management host 130, a multi-factor token can be installed (step 280). In this embodiment, the client 150 can store the received multi-factor tokens into a specific directory accessible by the credential management application to complete the installation of the multi-factor tokens.

Thereafter, when the user operates the client 150 to conduct an online transaction, the client 150 can complete the online transaction using the multi-factor token (step 290). In this embodiment, it is assumed that in the process of online transaction, the client 150 can transmit a multi-factor token and a mobile phone serial number to a transaction server that provides an online transaction, and the transaction server can be based on the voucher in the multi-factor message and the multi-factor token. The verification data is compared with the mobile phone serial number transmitted by the client 150 to confirm whether the trader who conducts the online transaction is the user himself. If not, the transaction server can reject the transaction, and if so, the transaction server can allow the client. End 150 continues the transaction process to complete the transaction.

In addition, if the voucher in the multi-factor message stored by the client 150 is encrypted, the trader of the client 150 needs to input the password before the transaction server confirms whether the trader is the user himself or herself according to the voucher in the multi-factor message. So that the transaction server can successfully decrypt the voucher to confirm the identity of the trader.

In this way, through this creation, the user can use the client to conveniently complete the online transaction in a secure environment with device authentication, without using a dynamic password, and at the same time, since the creation also confirms that the trader is the user himself, the trader's Transactions are also non-repudiation.

In summary, it can be seen that the difference between the present creation and the prior art is that the real-name authentication information application digital certificate is verified by the real-name authentication, and the multi-factor token is generated according to the applied digital certificate and the real-name authentication information, so that the client can have more basis. The technical means of completing the online transaction by the factor service can solve the problem that the security authentication of the online transaction existing in the prior art is not undeniable by the technical means, thereby achieving the technical effect of reducing the cost of providing the dynamic password.

Furthermore, the creation can be implemented in hardware, software or a combination of hardware and software, or in a centralized manner in a computer system or in a distributed manner in which different components are interspersed among several interconnected computer systems.

Although the embodiments disclosed in the present disclosure are as above, the contents are not intended to directly limit the scope of the patent protection of the present invention. Anyone who has the usual knowledge in the technical field of this creation, without any departure from the spirit and scope disclosed in this creation, makes some modifications to the form and details of the implementation of this creation, which are the patent protection of this creation. range. The scope of patent protection of this creation must be determined by the scope of the attached patent application.

120‧‧‧Relics application host
123‧‧‧Security components
125‧‧‧Voucher Registration Center
130‧‧‧Land Management Host
150‧‧‧Client
401‧‧‧Real-name authentication server
405‧‧‧Voucher Release Center Step 202‧‧‧Real-name authentication server provides client for real-name authentication Step 210‧‧‧ Real-name authentication server transmits real-name authentication information corresponding to the client to the token application host for registration step 220‧ ‧ ‧ 信 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请 申请Corresponding multi-factor beacon step 270‧‧‧ The token management host transmits multi-factor tokens to the client Step 280‧‧‧ Client installs multi-factor tokens Step 290‧‧‧ Clients use multi-factor tokens to complete online transactions

The first picture is a system architecture diagram of the multi-factor token generated by the author. Figure 2 is a flow chart of the method for generating multi-factor tokens proposed by the author.

120‧‧‧Relics application host

123‧‧‧Security components

125‧‧‧Voucher Registration Center

130‧‧‧Land Management Host

150‧‧‧Client

401‧‧‧Real-name authentication server

405‧‧‧Voucher Publishing Center

Claims (14)

A system for generating a multi-factor token, the system comprising: a token requesting host, configured to receive a real-name authentication information corresponding to a client, and apply for a digital certificate according to the real-name authentication information; and a token management host, Generating a multi-factor token corresponding to the client according to the digital certificate and the real-name authentication information. The system for generating multi-factor tokens according to claim 1, wherein the multi-factor token comprises one of a voucher corresponding to the client and one of the verification materials corresponding to the client. The system for generating a multi-factor token according to claim 2, wherein the verification data is a mobile phone serial number or a network card number. A system for generating a multi-factor token as described in claim 2, wherein the voucher is encrypted. The system for generating multi-factor tokens according to claim 1, wherein the token application host comprises a certificate authority (RA) and a security control component. The system for generating multi-factor tokens according to claim 1, wherein the token application host applies to the certificate authority (CA) for the digital certificate. The system for generating multi-factor tokens according to claim 1, wherein the client is a mobile phone or a computer. The system for generating multi-factor tokens according to claim 1, wherein the token management host is further configured to transmit the multi-factor token to the client, so that the client installs the multi-factor token, thereby allowing the client to Use this multi-factor token to complete online transactions. The system for generating a multi-factor token according to claim 8, wherein the token application host is further configured to obtain one of the installation target information corresponding to the client, and the token management host is further configured to use the installation target information. Transmitting the multi-factor token to the client. The system for generating multi-factor tokens according to claim 1, wherein the real-name authentication information is generated according to an email account and a mobile phone number authentication. The system for generating a multi-factor token according to claim 1, wherein the real-name authentication information is generated according to a public key. The system for generating multi-factor tokens according to claim 1, wherein the real-name authentication information is generated according to an online banking password and a mobile phone number authentication. For example, the system for generating multi-factor tokens according to claim 1 of the patent scope, wherein the real-name authentication information is generated based on the financial card, the financial card password and the mobile phone number authentication. The system for generating multi-factor tokens according to claim 1, wherein the real-name authentication information is generated according to an application authentication code and a mobile phone number authentication.